Versioning conventions

[eiriktsarpalis]

As we prepare for a 1.0 release, I think it would make sense to decide now on a versioning convention for MBrace releases. There seems to be an established adherence to semantic versioning, which I'm not sure whether is suitable for our needs given the problems we are currently facing with version tolerance (#53).

Given that MBrace.Core and MBrace.Azure are separate projects, and that a certain delay is required to roll out new MBrace.Core features to MBrace.Azure, another approach would be to adopt an odd/even versioning approach. For instance MBrace.Core 1.1 would incorporate prerelease features and changes that would be pushed to MBrace.Core and MBrace.Azure 1.2 as stable releases, etc.

Thoughts?

[dsyme]

My suggestion

• Definitely use semantic versioning for MBrace.Core from 1.0 onwards. It's a set of abstractions and a library and semantic versioning is really the right way to do things for that sort of thing.
• For MBrace.Azure it's less important, because people are less likely to build other libraries on top of this (we hope) so probably just stick with a 1.0, 1.1 release, or just use semantic versioning too.

[eiriktsarpalis]

@dsyme do you think that MBrace.Azure releases should maintain version parity with core, at least w.r.t. Major/Minor version numbers?

[dsyme]

No, I think decouple them. With more fabric mappings coming in the future we'll be doing everyone a favour to decouple, otherwise it will look like MBrace.Azure gets special status.