You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Turk <mt...@apache.org> on 2010/10/21 09:02:28 UTC
Tagging JK 1.2.31
Hi,
Seems we are fine for 1.2.31 now that httpd 2.3
compiles without problems.
I plan to tag 1.2.31_RC1 and make release
candidate set of sources and bin at the ususal place.
If voted we would just need to svn mv 1.2.31_RC1 1.2.31
If someone again "needs more time for testing" :)
the release process is just good as any.
I hope I'll do all that by tomorrow which would
give us a plenty of time for a vote, so we can
have that out next week.
Comments?
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging JK 1.2.31
Posted by Tim Whittington <ti...@apache.org>.
+1
I just committed a minor fix for the Apache 2.0 build with VS 2005 -
not a blocker.
cheers
tim
On Thu, Oct 21, 2010 at 8:02 PM, Mladen Turk <mt...@apache.org> wrote:
> Hi,
>
> Seems we are fine for 1.2.31 now that httpd 2.3
> compiles without problems.
>
> I plan to tag 1.2.31_RC1 and make release
> candidate set of sources and bin at the ususal place.
> If voted we would just need to svn mv 1.2.31_RC1 1.2.31
>
> If someone again "needs more time for testing" :)
> the release process is just good as any.
> I hope I'll do all that by tomorrow which would
> give us a plenty of time for a vote, so we can
> have that out next week.
>
>
> Comments?
>
> Regards
> --
> ^TM
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging JK 1.2.31
Posted by sebb <se...@gmail.com>.
On 21 October 2010 16:02, Rainer Jung <ra...@kippdata.de> wrote:
> On 21.10.2010 14:48, Mladen Turk wrote:
>>
>> On 10/21/2010 02:29 PM, Rainer Jung wrote:
>>>
>>> On 21.10.2010 09:02, Mladen Turk wrote:
>>>>
>>>> Hi,
>>>>
>>>
>>> Hmmm, the problem with the RCs is:
>>>
>>> - either we don't want to change any contents of the release between
>>> the last RC and the release. Then the RCs do not contain any
>>> indication that they are actually RCs. So they might circulate and
>>> actually look like an official release.
>>> - or we add RC1 or whatever somewhere to the files and version
>>> strings. Then we have to reroll after the RC finally is approved (and
>>> I think to vote again)
>>>
>>
>> Why?
>> I mean tag something like _RC1 if voted fine, just rename the tag to
>> release.
>> It will contain the same thing in there no mater what trunk points to.
>> If not create fixes in the trunk, create _RC2 tag and iterate again.
>>
>> svn mv is just a handy tool for that.
>> If you want't to keep the _RC1 (for what ever reason) then
>> just do a svn cp 1.2.31_RC1 1.2.31
>
> My point is: once we circulate something, it should be clearly
> distinguishable from anything else we start to circulate. If the RC doesn't
> contain in it any indication of RC, you will never be able to tell, whether
> someone is using an RC1, RC2 or final release. All of them will identify
> itself as 1.2.31.
>
> Previously we circulated clearly distinguishable versions to do some pre
> voting testing and when we had the impression it looks good, we rolled the
> final version and voted.
>
> The other way would be like TC does it, namely tag a version and if it fails
> tag a new version. I did like our previous approach better. I'm not very
> comfortable with the possibilities of having RC1, RC2 etc. all of them
> identifying themselves as the real release.
If the archives contain the RCn suffix, would that not be sufficient?
The archives should not be put on general release, so it would only be
reviewers that have copies and they should know.
If you wish to distinguish the contents, then one possible solution is
to include the SVN revision somewhere in the code.
That would be useful anyway.
Also, any separately released items need to have hashes and sigs, so
one can distinguish the files if necessary.
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging JK 1.2.31
Posted by Mladen Turk <mt...@apache.org>.
On 10/21/2010 05:59 PM, Rainer Jung wrote:
>
> 1.2.31 (r1003456)
>
> What file name do you plan for the RC source tarball?
The same as a release.
I'll put them in the p.a.o/~mturk for potential voters.
Again, this is not a release, release candidate or something third.
It is my proposal made from the particular tag, which if
voted will be promoted to the release.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging JK 1.2.31
Posted by Rainer Jung <ra...@kippdata.de>.
On 21.10.2010 17:44, Mladen Turk wrote:
> On 10/21/2010 05:02 PM, Rainer Jung wrote:
>> On 21.10.2010 14:48, Mladen Turk wrote:
>>
>> My point is: once we circulate something, ...
>
>
> But the point is that we don't circulate that.
> It's supposed to be used only by PMC members that
> would vote or no vote for that release.
>
> We are not creating something that goes out.
> It's simply a mechanism we are using to verify
> that we won't announce something with broken packaging.
Would you oppose, if I find a simple way of adding the revision number
to the exposed version, like
1.2.31 (r1003456)
What file name do you plan for the RC source tarball?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging JK 1.2.31
Posted by Mladen Turk <mt...@apache.org>.
On 10/21/2010 05:02 PM, Rainer Jung wrote:
> On 21.10.2010 14:48, Mladen Turk wrote:
>
> My point is: once we circulate something, ...
But the point is that we don't circulate that.
It's supposed to be used only by PMC members that
would vote or no vote for that release.
We are not creating something that goes out.
It's simply a mechanism we are using to verify
that we won't announce something with broken packaging.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging JK 1.2.31
Posted by Rainer Jung <ra...@kippdata.de>.
On 21.10.2010 14:48, Mladen Turk wrote:
> On 10/21/2010 02:29 PM, Rainer Jung wrote:
>> On 21.10.2010 09:02, Mladen Turk wrote:
>>> Hi,
>>>
>>
>> Hmmm, the problem with the RCs is:
>>
>> - either we don't want to change any contents of the release between
>> the last RC and the release. Then the RCs do not contain any
>> indication that they are actually RCs. So they might circulate and
>> actually look like an official release.
>> - or we add RC1 or whatever somewhere to the files and version
>> strings. Then we have to reroll after the RC finally is approved (and
>> I think to vote again)
>>
>
> Why?
> I mean tag something like _RC1 if voted fine, just rename the tag to
> release.
> It will contain the same thing in there no mater what trunk points to.
> If not create fixes in the trunk, create _RC2 tag and iterate again.
>
> svn mv is just a handy tool for that.
> If you want't to keep the _RC1 (for what ever reason) then
> just do a svn cp 1.2.31_RC1 1.2.31
My point is: once we circulate something, it should be clearly
distinguishable from anything else we start to circulate. If the RC
doesn't contain in it any indication of RC, you will never be able to
tell, whether someone is using an RC1, RC2 or final release. All of them
will identify itself as 1.2.31.
Previously we circulated clearly distinguishable versions to do some pre
voting testing and when we had the impression it looks good, we rolled
the final version and voted.
The other way would be like TC does it, namely tag a version and if it
fails tag a new version. I did like our previous approach better. I'm
not very comfortable with the possibilities of having RC1, RC2 etc. all
of them identifying themselves as the real release.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging JK 1.2.31
Posted by Mladen Turk <mt...@apache.org>.
On 10/21/2010 02:29 PM, Rainer Jung wrote:
> On 21.10.2010 09:02, Mladen Turk wrote:
>> Hi,
>>
>
> Hmmm, the problem with the RCs is:
>
> - either we don't want to change any contents of the release between the last RC and the release. Then the RCs do not contain any indication that they are actually RCs. So they might circulate and actually look like an official release.
> - or we add RC1 or whatever somewhere to the files and version strings. Then we have to reroll after the RC finally is approved (and I think to vote again)
>
Why?
I mean tag something like _RC1 if voted fine, just rename the tag to release.
It will contain the same thing in there no mater what trunk points to.
If not create fixes in the trunk, create _RC2 tag and iterate again.
svn mv is just a handy tool for that.
If you want't to keep the _RC1 (for what ever reason) then
just do a svn cp 1.2.31_RC1 1.2.31
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tagging JK 1.2.31
Posted by Rainer Jung <ra...@kippdata.de>.
On 21.10.2010 09:02, Mladen Turk wrote:
> Hi,
>
> Seems we are fine for 1.2.31 now that httpd 2.3
> compiles without problems.
Yep.
> I plan to tag 1.2.31_RC1 and make release
> candidate set of sources and bin at the ususal place.
> If voted we would just need to svn mv 1.2.31_RC1 1.2.31
Hmmm, the problem with the RCs is:
- either we don't want to change any contents of the release between the
last RC and the release. Then the RCs do not contain any indication that
they are actually RCs. So they might circulate and actually look like an
official release.
- or we add RC1 or whatever somewhere to the files and version strings.
Then we have to reroll after the RC finally is approved (and I think to
vote again)
So if we do an RC, I would say the RC should be easily identifiable as
an RC (version strings, download file names) and the purpose is simply
to identify any problems, before we proceed to the real tag and vote. Is
that what you want to do? It would be the same we did in the past except
for calling it RCX instead of rXXXXXX-dev.
> If someone again "needs more time for testing" :)
> the release process is just good as any.
> I hope I'll do all that by tomorrow which would
> give us a plenty of time for a vote, so we can
> have that out next week.
OK, thanks.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org