mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeroen Brattinga" <jeroen.bratti...@gmail.com>
Subject Re: Sum-up: Versioning Scheme
Date Sun, 29 Oct 2006 09:13:45 GMT
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 <trustin@gmail.com>:
>
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message