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:

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.0 can
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 st
art
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
--
[url]http://gleamynode.net/" target="_blank">http://cwiki.apache.org/confluence/...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

[ Post a follow-up to this message ]

[OT]

On 10/29/06, Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 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/...umbering+Scheme[/vbc
ol]

I have moved the page to:

http://cwiki.apache.org/confluence/...umbering+Scheme

Seemed to be a better place to live for that document.

And a very important thing is that "We must always give the URLs from
wiki through the autoexported pages which will be something like:

http://cwiki.apache.org/DIRxPMGT/Ve...umbering+Scheme

This is important to keep the Confluence instance alive. However the
autoexport plugin for Confluence currently does not as intended due to
incompatibility problems with the latest Confluence version. So we do
not have static pages for some of out already edited spaces. I hope
all will be fine soon.
[vbcol=seagreen]
> 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 futu
re
> 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 ki
nd
> of weird.  Releasing 2.0-M1/2/3/4...and then RC1/2/3... and finally 2.0 ca
n
> 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 opinion
s
> 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


--
Ersin

[ Post a follow-up to this message ]

Trustin Lee wrote:
> 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:
>
> [url]http://cwiki.apache.org/confluence/display/directory/Version+Numbering+Scheme[/u
rl]
>
>
> 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.

Please don't put too much emphasis on the 1.0 -> 1.5 move as something
cute to mean that we went to JDK 5.0.  We could have just picked 1.3 or
1.7.

The key point was we do not want to go to 1.1 because we're changing a lot.

> 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.0 ca
n
> 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.

You mean in my description of it on the cwiki?

> 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 opinion
s
> and to improve our version numbering scheme.

I have to agree with Peter that this thread is in danger of turning into
a bike shed argument.

Alex

[ Post a follow-up to this message ]