Versioning: Can Be Done Right?
JSR #277: Stanley Ho explains versioning... Sounds like a bad idea to me...
I have commented his post. Anyway, I think the idea deserves its own blog post: I hope to see some discussion about it. And I really wonder what your opinions are.
Here it is:
Major? Minor? Micro? Update? 3 or 4 numbers?
IMHO, doesn't matter at all...
Stanley, what happened to or what is wrong with my proposal of versioning?
With proposed solution (version compatibility based on version history), module system would not have to do any potentially incorrect assumptions, it would not enforce the-one-versioning-policy-to-rule-them-all ... simply, it would be more flexible
(a)library client MAY NOT know what future versions he will be compatible with, but
(b)library provider DOES know if he breaks anything from the past or notâ€¦
You could have versioning sequence like this (trying to make my point, not to be factually exact):
- merlin (backward-compatible=false)
- tiger (backward-compatible=false)
- 6.0 (backward-compatible=false)
Version 7.0 might break your app or might notâ€¦ You don't know TODAY. Developers of 7.0 WILL know betterâ€¦ TOMORROW
Your dependency could read like:
- depends: merlin (ignore:mantis) #mantis has some known regression bug
Module system gives you either Merlin, Hopper, Tiger or 6.0.
When 7.0 will be released, you might end up running under 7.0 as well, if it WILL be declared compatibleâ€¦ It not (backward-compatible=false), 7.0 won't get into your wayâ€¦
I would LOVE to know what is wrong whit THIS approachâ€¦ Because to me this is more sound a solution than playing games with numbers...