On 23.12.2009 10:33, Konstantin Kolinko wrote:
2009/12/23 Mladen Turk<mt...@apache.org>:
On 12/23/2009 02:12 AM, Rainer Jung wrote:
release candidates (marking the files with rcX or dev or whatever) the
only safe thing would be to burn version number 6.0.21 and go for 6.0.22.
+1
Let's make a proper release.
+1
I'd suggest to make a release on a specific SVN revision instead tag.
That way if voted it can easily be tagged as 6.0.22 (that revision
instead 6.0.x trunk)
Having that, RM can have as many candidates without re-tagging or
creating useless tags.
1. Rainer states a valid point that if those files are named "6.0.22"
someone can download them from people.apache.org and claim later that
it is ours.
If those are named differently, will PGP signatures still apply?
Though it would be good to do some testing with a 6.0.0-dev build as a
RC after several months of active development, or after reconfiguring
the build environment.
2. Do we change 6.0.0-dev -> 6.0.22 in the properties file in SVN
before that revision, or in the tag only, or change it only locally?
I would prefer it to be changed in the tag.
3. While RC voting goes, should we make "6.0.(n+1)" section
in changelog.xml and add new items there, optionally moving them
into "6.0.n" section if voting fails?
I think it is OK to trash one or more version numbers. It preserves consistency.
And will we ever beat HTTPD with their *.*.63 for 2.0.x?
I expect making RC from some svn revision and then rebrand as release
after voting needs some experimentation in order to find a stable
process for it (where is the version number hidden in the RC, how easy
can the RC be differentiated from the full release). Using an RC tag or
an svn revision for that will be the smallest problem.
We can inspect, how the commons people do their RCs and releases.
So I suggest we try that for TC 7 and find out how to do that in a good
way (or not) before we try with 6.0. Let's stick to the existing process
for 6.0 and do the experiments with 7.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
