I'm still convinced that we should look at the current 'problem' (Java 1.4--> Java 1.5) and not try to create a general rule out of it. Yes, I know, it's not the 'programmers way' (always trying to create the most ideal, general purpose rules), but I think it fits the current circumstances.
What to do with Java 1.6, 1.7 etc.? I have no idea at the moment, but I don't think that's really a problem. The rules that are stated at http://cwiki.apache.org/confluence/display/DIRxPMGT/Version+Numbering+Schemeare pretty clear. On the "may or may not" --> I'll vote for "may". Jeroen Brattinga 2006/10/29, Trustin Lee <[EMAIL PROTECTED]>:
Hi all, The previous thread on versioning scheme is becoming very long, so I want to split it into two by summarizing what we agreed on. Alex summarized our current versioning scheme here: http://cwiki.apache.org/confluence/display/directory/Version+Numbering+Scheme I agree with his idea mostly, but there are two points to raise: 1. 1.5 -> 2.0 vs 1.9 -> 2.0 vs 2.1 -> 2.2 1.5 is a very arbitrary number and this rule cannot be applied to the future similar changes. What happens if we move to Java 6? What happens we already released 1.7 and if we move to Java 7? 1.9 has also a similar problem; what happens if we already released 1.8? There's no way to distinguish from previous releases because we are out of bullet. 2.1 -> 2.2 also has a problem that 2.0 will never be released, which is kind of weird. Releasing 2.0-M1/2/3/4...and then RC1/2/3... and finally 2.0can be a solution, but it makes the even/odd scheme pointless because we can just use 'M{number}' to state that it's unstable. Of course, we can start over with this whole new scheme. 2. Clarify the meaning of minor version number. 'may or may not' sounds very ambiguous. We need to clarify it. We can just go 1.5 or 1.9 not settling down the version numbering scheme, but we will encounter the same problem on and on. I'm not a perfectionist, but I want to set up a nice rule that can be applied for as many cases as we can cover. Now the thread is hot, it's a great time to gather all opinions and to improve our version numbering scheme. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
-- Jeroen Brattinga
