You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2010/08/20 18:26:59 UTC

Tomcat Version Numbers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I have a question about Tomcat versions numbers, prompted by the recent
announcement of TC 7.0.2 beta.

Will the TC 7.x versions numbers increase like 7.0.3, 7.0.4, and then at
some point it will be considered "stable"? That sounds like Tomcat 7.0.0
is not actually a release version, right? Given that, there's no telling
which 7.0 version will be the first stable one, right?

Is the same true for TC 6.0? I'm guessing yes. What was the first
version of TC 6.0 that was considered stable?

Browsing to http://archive.apache.org/dist/tomcat/tomcat-6/ seems to
indicate that 6.0.10 was the first version not marked as "alpha" or "beta".

I'm not entirely sure why, but I find this confusing. :( It's not that I
don't get it... it's that I have a deep-seated need for the release
version to be called 7.0.0 for some reason. Is there a reason that the
alphas and betas are not called something like 7.0.0-beta1 and
7.0.0-beta2, etc.?

Just curious.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxurNMACgkQ9CaO5/Lv0PDR8gCfa6XXOTZ0MUs6dQisDeB0VLtV
kSQAnjpda4ij7YpmzCDqsRsBxXj3Qy3u
=tqwl
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Tomcat Version Numbers

Posted by André Warnier <aw...@ice-sa.com>.
Len Popp wrote:
> On Fri, Aug 20, 2010 at 12:26, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> It's not that I
>> don't get it... it's that I have a deep-seated need for the release
>> version to be called 7.0.0 for some reason.
> 
> Call me cynical, but I naturally assume that a major new version will
> have more bugs (no matter how much beta testing was done), and I feel
> much safer installing a x.0.1 release. So I find the Tomcat numbering
> system more reassuring. :-)
> --

And if the Tomcat developers had an ounce of marketing sense, they would release the very 
first version with a number no lower than 7.0.62 or so, to make people see (think?) that 
it has already been extensively tested and patched.
One can really see that this is Open Source Software, here.
;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Tomcat Version Numbers

Posted by Len Popp <le...@gmail.com>.
On Fri, Aug 20, 2010 at 12:26, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> It's not that I
> don't get it... it's that I have a deep-seated need for the release
> version to be called 7.0.0 for some reason.

Call me cynical, but I naturally assume that a major new version will
have more bugs (no matter how much beta testing was done), and I feel
much safer installing a x.0.1 release. So I find the Tomcat numbering
system more reassuring. :-)
--
Len

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Tomcat Version Numbers

Posted by Mark Thomas <ma...@apache.org>.
On 20/08/2010 17:36, Caldarale, Charles R wrote:
>> Given that, there's no telling which 7.0 version will be the 
>> first stable one, right?
> 
> Mark seems to be close to recommending stable, but yes, there's no telling.

Ultimately it is a community decision. The more folks that use the betas
and provide feedback - particularly on the release votes - the better.
Personally, I'm undecided. I'll probably wait until I have the ASF JIRA
instances running on Tomcat 7 before I am happy to vote stable. That
said, I know some folks that were using 7.0.0 in production.

One of my aims as the current Tomcat 7 release manager is to a) keep on
top of the bugs and b) release frequently enough that folks can use
Tomcat 7 and if they hit an issue get a fix in a couple of weeks.

In terms of keeping on top of bugs, the better the bug reports the
easier this is. On that topic: a few tips based on what is currently
driving me nuts:
- Test against the current source code. Building Tomcat 7 is *really*
easy and if you test against the current source code folks don't waste
time tracking down bugs that have already been fixed
- Provide a *simple as possible* test case
- Provide the source for your test case
- Test cases in the form of a new unit test are ideal
- The test case should actually demonstrate the error reliably

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Tomcat Version Numbers

Posted by Mark Thomas <ma...@apache.org>.
On 25/08/2010 16:23, Christopher Schultz wrote:

> For those who never read http://tomcat.apache.org/whichversion.html, or
> don't understand it (btw: that page says 7.0.0 is the current version of
> the 7.0.x versions), downloading the highest version number available
> (7.0.2) might not be such a good idea.

My bad. I missed updating that page when I released 7.0.2. I've fixed it
and it should sync to the live servers in an hour or so.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Tomcat Version Numbers

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: Tomcat Version Numbers

> Okay. Does that mean that:
> [DIR] v6.0.2-alpha/           2006-11-16 00:02    -
> [DIR] v6.0.2-beta/            2006-11-16 00:02    -
> [DIR] v6.0.2/                 2006-11-16 00:02    -

> ...means that 6.0.2, 6.0.2-alpha, and 6.0.2-beta are all the 
> exact same sets of files, just with different tag names?

Exactly.

> I can download 7.0.2 today (without fiddling with SVN) by going to
> http://tomcat.apache.org/download-70.cgi (no warning about it's
> beta-ness before you get to this page)

Actually, there is warning: on the Tomcat home page, under Tomcat 7.0.2 Released, it says:

"The Apache Tomcat Project is proud to announce the release of version 7.0.2 beta..."

It's also noted prominently on the "Which version?" page, which also contains the definition of alpha/beta/stable in the Tomcat context.

> the only place on the page where you might get the idea that 
> this isn't ready for production is the word "BETA" in the title
> of the release section. It's quite easy to miss.

How would you propose highlighting it?

> (Note that this isn't a proper title, even: it's an <a> within 
> a <font> within a <td>

No, that's just the anchor; the text displayed comes from <strong>7.0.2 BETA</strong> (still within the <font>, as it should be).

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


Re: Tomcat Version Numbers

Posted by Rainer Jung <ra...@kippdata.de>.
On 25.08.2010 20:57, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chuck,
>
> On 8/25/2010 11:15 AM, Caldarale, Charles R wrote:
>>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>>> Subject: Re: Tomcat Version Numbers
>>
>>> why not have a tag progression that looks like this:
>>
>>> 6.0.0-alpha
>>> 6.0.0-beta1
>>> 6.0.0-beta2
>>
>> Because there are no changes to an x.y.z level, regardless of how its marking progresses.  _Any_ changes require a new dot number.  The 6.0.0-alpha and 6.0.0 are identical; only the labeling changed to indicate that the particular level had progressed through more testing.  Your suggestion causes no end of confusion, since there will be flavors of 6.0.0 running around with different content.
>
> Okay. Does that mean that:
>
> [DIR] v6.0.2-alpha/           2006-11-16 00:02    -
> [DIR] v6.0.2-beta/            2006-11-16 00:02    -
> [DIR] v6.0.2/                 2006-11-16 00:02    -
>
> ...means that 6.0.2, 6.0.2-alpha, and 6.0.2-beta are all the exact same
> sets of files, just with different tag names?

On the file system, the directories named *alpha and *beta are symlinks 
to the one without suffix.

Looking at the list archives I would say the RM found it easiest to 
always produce the directory without suffix and then add symlinks 
according to the release status.

 From this digging into history I would say:

6.0.0: alpha
6.0.1: alpha
6.0.2: beta
6.0.4: alpha
6.0.6: alpha
6.0.7: beta
6.0.8: alpha
6.0.9: beta

Starting with 6.0.10: stable

And yes it is possible, that a release after a beta release is again 
alpha, or a release after stable is again beta incase there is a major 
regression. So the use of the terminology is slightly non-standard.

Regards,

Rainer


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Tomcat Version Numbers

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 8/25/2010 11:15 AM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
>> Subject: Re: Tomcat Version Numbers
> 
>> why not have a tag progression that looks like this:
> 
>> 6.0.0-alpha
>> 6.0.0-beta1
>> 6.0.0-beta2
> 
> Because there are no changes to an x.y.z level, regardless of how its marking progresses.  _Any_ changes require a new dot number.  The 6.0.0-alpha and 6.0.0 are identical; only the labeling changed to indicate that the particular level had progressed through more testing.  Your suggestion causes no end of confusion, since there will be flavors of 6.0.0 running around with different content.

Okay. Does that mean that:

[DIR] v6.0.2-alpha/           2006-11-16 00:02    -
[DIR] v6.0.2-beta/            2006-11-16 00:02    -
[DIR] v6.0.2/                 2006-11-16 00:02    -

...means that 6.0.2, 6.0.2-alpha, and 6.0.2-beta are all the exact same
sets of files, just with different tag names?

>> Again, this is partly because I feel a certain sense of order which
>> requires releases to be X.0.0.
> 
> That makes absolutely no sense to me.

*shrug*

>> My original question was sparked by the fact that 7.0.2 was released
>> which would, merely by the version number, indicate to me that it was a
>> stable bugfix release to the 7.0 line.
> 
> 7.0.2 never got out of beta, nor did any of its 7.0.x predecessors.  Why would you think it's stable?
> 
>> downloading the highest version number available
>> (7.0.2) might not be such a good idea.
> 
> A version won't make it into the archives unless it's alpha, beta, or stable - and it will be marked as such, so you have a pretty good idea of how well it's been exercised.  If you're looking at SVN, you're on your own.

I can download 7.0.2 today (without fiddling with SVN) by going to
http://tomcat.apache.org/download-70.cgi (no warning about it's
beta-ness before you get to this page) and then the only place on the
page where you might get the idea that this isn't ready for production
is the word "BETA" in the title of the release section. It's quite easy
to miss.

(Note that this isn't a proper title, even: it's an <a> within a <font>
within a <td> and therefore has no structural significance to the page.
But that's a completely separate issue.)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx1Z4UACgkQ9CaO5/Lv0PDNawCeJEJbgyF9fQjYDKlm9R2FRhDO
HG8Amwe1/EPaEmaA595PLjfmaeS8B9t7
=iNxE
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Tomcat Version Numbers

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
> Subject: Re: Tomcat Version Numbers

> there's a 6.0.0-alpha, and then a 6.0.0, unqualified.
> Does that mean that 6.0.0 was stable -- at least after
> the alpha stage?

Yes. (I missed the unmarked 6.0.0 leg.)

> why was 6.0.2 relegated to beta (and, apparently,
> alpha) status?

Because there hadn't been enough field testing to consider it stable.  As more testing occurred, and more reports received, the marking was upgraded.

> I'm sure I'm muddying the waters by using the term "stable" which
> generally means API-compatible, not necessarily production-quality.

I've always considered "stable" to mean production-quality; it has nothing to do with API compatibility.

> why not have a tag progression that looks like this:

> 6.0.0-alpha
> 6.0.0-beta1
> 6.0.0-beta2

Because there are no changes to an x.y.z level, regardless of how its marking progresses.  _Any_ changes require a new dot number.  The 6.0.0-alpha and 6.0.0 are identical; only the labeling changed to indicate that the particular level had progressed through more testing.  Your suggestion causes no end of confusion, since there will be flavors of 6.0.0 running around with different content.

> Again, this is partly because I feel a certain sense of order which
> requires releases to be X.0.0.

That makes absolutely no sense to me.

> My original question was sparked by the fact that 7.0.2 was released
> which would, merely by the version number, indicate to me that it was a
> stable bugfix release to the 7.0 line.

7.0.2 never got out of beta, nor did any of its 7.0.x predecessors.  Why would you think it's stable?

> downloading the highest version number available
> (7.0.2) might not be such a good idea.

A version won't make it into the archives unless it's alpha, beta, or stable - and it will be marked as such, so you have a pretty good idea of how well it's been exercised.  If you're looking at SVN, you're on your own.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

Re: Tomcat Version Numbers

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter,

On 8/25/2010 10:30 AM, Peter Crowther wrote:
> On 25 August 2010 15:23, Christopher Schultz
> <ch...@christopherschultz.net>wrote:
> 
>> Again, this is partly because I feel a certain sense of order which
>> requires releases to be X.0.0.
>>
>> Why?  And by "release" do you mean "stable, production-quality releases
> that we'll stake our reputations on" (in which case almost every x.0.0 would
> in reality fail the test) or do you mean "released outside the development
> team"?
> 
> Not saying it's "wrong" (I tend to avoid "right" and "wrong" due to
> relativism), just interested by the expectation.

Microsoft products notwithstanding, I kind of expect that release X.0.0
will be appropriate for general-purpose use. That wasn't true of 6.0.0
and 7.0.0. One had to wait around until 6.0.1 or 6.0.10 or whatever
before 6.0.x was really "ready". I'm sure there will be an announcement
at some point that 7.0.5 (or whatever it happens to be) is stable (no
API changes) and production-quality in that no correctness tests fail,
but it would be nice to just /know/ that 7.0.0 is "the release" and
everything after that is bugfixes and stuff. Instead, 7.0.5 (or
whatever) will be "the release" which is just... surprising.

It's not really tripping me up: don't worry. I'm thinking about casual
readers/downloaders who don't see the "beta" in the name (which, by the
way, only appears in a single place on
http://tomcat.apache.org/download-70.cgi, with no specific warning about
how it's a beta release and not appropriate for production).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx1L/cACgkQ9CaO5/Lv0PCihgCcDLX2J5RWx+M9rB1R/tLLuvMI
m4oAn0WCXF4ajP1MK/3bBpyB1Ut+4lkt
=nCnY
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Tomcat Version Numbers

Posted by Peter Crowther <pe...@melandra.com>.
On 25 August 2010 15:23, Christopher Schultz
<ch...@christopherschultz.net>wrote:

> Again, this is partly because I feel a certain sense of order which
> requires releases to be X.0.0.
>
> Why?  And by "release" do you mean "stable, production-quality releases
that we'll stake our reputations on" (in which case almost every x.0.0 would
in reality fail the test) or do you mean "released outside the development
team"?

Not saying it's "wrong" (I tend to avoid "right" and "wrong" due to
relativism), just interested by the expectation.

Cheers,

- Peter

Re: Tomcat Version Numbers

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 8/20/2010 12:36 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Subject: Tomcat Version Numbers
>>
>> What was the first version of TC 6.0 that was considered stable?
> 
> Looks like 6.0.1 was the first release marked stable.
> 
>> Browsing to http://archive.apache.org/dist/tomcat/tomcat-6/ seems 
>> to indicate that 6.0.10 was the first version not marked as "alpha"
>> or "beta".
> 
> You missed 6.0.1.

My confusion persists. Here is a sample of the subdirectory names from
the above directory:

[DIR] v6.0.0-alpha/           2006-10-21 00:02    -
[DIR] v6.0.0/                 2006-10-21 00:02    -
[DIR] v6.0.1-alpha/           2006-11-08 12:52    -
[DIR] v6.0.1/                 2006-11-08 12:52    -
[DIR] v6.0.10/                2007-02-26 17:13    -
[DIR] v6.0.13/                2007-05-14 15:32    -
[DIR] v6.0.14/                2007-08-09 12:35    -
[DIR] v6.0.16/                2008-02-06 23:55    -
[DIR] v6.0.18/                2008-07-30 09:51    -
[DIR] v6.0.2-alpha/           2006-11-16 00:02    -
[DIR] v6.0.2-beta/            2006-11-16 00:02    -
[DIR] v6.0.2/                 2006-11-16 00:02    -

So, there's a 6.0.0-alpha, and then a 6.0.0, unqualified. Does that mean
that 6.0.0 was stable -- at least after the alpha stage? What about,
say, 6.0.2? If 6.0.0 (or even 6.0.1) was stable, why was 6.0.2 relegated
to beta (and, apparently, alpha) status? Were those pre-6.0.2 tags with
6.0.2 being the release version? At some point, the -alpha and -beta
qualifications disappear (after 6.0.9, which is why I concluded that
6.0.10 was the first release version).

I'm sure I'm muddying the waters by using the term "stable" which
generally means API-compatible, not necessarily production-quality.

>> Is there a reason that the alphas and betas are not called 
>> something like 7.0.0-beta1 and 7.0.0-beta2, etc.?
> 
> Simplicity.  When a branch is tagged, its number is fixed at that point, and the content frozen.  As field testing progresses, the designation of the branch may be advanced from alpha, to beta, to stable - with no code changes.  Or problems may be discovered, code committed, and a new branch tagged, with a new number.

The above does not strike me as simple. If you can have 6.0.0-alpha and
6.0.2-beta, why not have a tag progression that looks like this:

6.0.0-alpha
6.0.0-beta1
6.0.0-beta2
6.0.0-beta3
6.0.0 [release]
6.0.1 [release]
6.0.2 [release]

Again, this is partly because I feel a certain sense of order which
requires releases to be X.0.0.

My original question was sparked by the fact that 7.0.2 was released
which would, merely by the version number, indicate to me that it was a
stable bugfix release to the 7.0 line. In fact, it is another in a
string of non-production-quality releases.

For those who never read http://tomcat.apache.org/whichversion.html, or
don't understand it (btw: that page says 7.0.0 is the current version of
the 7.0.x versions), downloading the highest version number available
(7.0.2) might not be such a good idea.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx1J1kACgkQ9CaO5/Lv0PApJACeNBcuF+cQkMykU1cqpZe3/NeO
sIwAoICZpWqCA0G8e7aEW8Zo8I2CkzS6
=jnk9
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Tomcat Version Numbers

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Tomcat Version Numbers
> 
> Will the TC 7.x versions numbers increase like 7.0.3, 7.0.4, 
> and then at some point it will be considered "stable"?

Yes.

> That sounds like Tomcat 7.0.0 is not actually a release version,
> right?

No, Tomcat 7.0.0 was a beta release.

> Given that, there's no telling which 7.0 version will be the 
> first stable one, right?

Mark seems to be close to recommending stable, but yes, there's no telling.

> Is the same true for TC 6.0?

Yes.

> What was the first version of TC 6.0 that was considered stable?

Looks like 6.0.1 was the first release marked stable.

> Browsing to http://archive.apache.org/dist/tomcat/tomcat-6/ seems 
> to indicate that 6.0.10 was the first version not marked as "alpha"
> or "beta".

You missed 6.0.1.

> Is there a reason that the alphas and betas are not called 
> something like 7.0.0-beta1 and 7.0.0-beta2, etc.?

Simplicity.  When a branch is tagged, its number is fixed at that point, and the content frozen.  As field testing progresses, the designation of the branch may be advanced from alpha, to beta, to stable - with no code changes.  Or problems may be discovered, code committed, and a new branch tagged, with a new number.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.