On 23.12.2009 00:45, Konstantin Kolinko wrote:
2009/12/22 Mark Thomas<ma...@apache.org>:
(...)
Since we are going to have to re-tag anyway, it would be good if the
patches required to fix the various niggles above were applied before
the tag.
Mark
+1 to re-tag.
And I would like the fix to 47413 to be included in it. Patch already
proposed, though there might be comments.
To be sure: while applying the patches, we are still updating the
"6.0.21" section of changelog.xml?
That is, everybody agrees that the next tag will be 6.0.21 again? I am
+1 to drop the current TOMCAT_6_0_21/ and recreate it after the fixes
are applied.
IMHO: Our whole release process happens in public. So our artefacts can
be retrieved from the dev download pages and from looking at the files
there is nothing to decide, whether it is a later withdrawn release
candidate of 6.0.21 or the real release. So since we don't do real
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.
The same problem IMHO applies to editing files in an svn tag (at least
if more than a couple of minutes have passed since tagging). After
editing it's not any more a tag that uniquely describes one version of
the code, instead it becomes a branch.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
