You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bridges-dev@portals.apache.org by David Sean Taylor <da...@bluesunrise.com> on 2007/02/21 16:39:25 UTC
[VOTE] 1.0.1 Release
I would like to propose an official release date of version 1.0.1 as
February 27, 2007 (Tuesday)
I would also like to propose that all feature work complete by today,
and that only documentation and bug fix work continues thru Monday
night.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: [VOTE] 1.0.1 Release
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
David Sean Taylor wrote:
> I would like to propose an official release date of version 1.0.1 as
> February 27, 2007 (Tuesday)
> I would also like to propose that all feature work complete by today,
> and that only documentation and bug fix work continues thru Monday night.
+1
Thanks,
shinsuke
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: bridges-dev-help@portals.apache.org
>
>
--------------------------------------
Start Yahoo! Auction now! Check out the cool campaign
http://pr.mail.yahoo.co.jp/auction/
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: [VOTE] 1.0.1 Release
Posted by Carsten Ziegeler <cz...@apache.org>.
Santiago Gala wrote:
> El mié, 21-02-2007 a las 07:39 -0800, David Sean Taylor escribió:
>> I would like to propose an official release date of version 1.0.1 as
>> February 27, 2007 (Tuesday)
>> I would also like to propose that all feature work complete by today,
>> and that only documentation and bug fix work continues thru Monday
>> night.
>>
>
> I read recently that it does not make sense to cut a release *after*
> voting it. Actually, the process they do in httpd and a few other
> projects is more like a two phase commit:
>
> - vote a (fuzzy) calendar
> - feature freeze, alpha-N or rc-N releases
> - once one of the rc-N releases reveals as good enough, it is voted and
> becomes the version
>
> The advantages of this strategy is that the committers vote on a
> concrete tarball, with all its bugs and, in theory, no surprises. As
> only very minor fixes are allowed between rc-N and rc-N+1, it would be
> difficult to introduce heavy bugs in the "final" code.
>
> As Roy put it, it only makes sense to vote on concrete code, not on
> "intentions to do".
>
> So I'd say, start feature freeze whenever, and repeat a vote when one of
> the rc or snapshots seem to be ready to be released.
>
Yes, this is more or less a requirement for releases at Apache. The vote
has to be done on a concrete tarball. So this means whenever you're
ready prepare the tarball (including tagging etc) and vote on it.
If for any reason the vote fails, this means increasing the version
number! So if you prepare a 1.0.1 release, the vote fails, the next
official release will be 1.0.2 to avoid confusion. There was an
interesting thread recently on the jackrabitt developer list about this
topic.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: [VOTE] 1.0.1 Release
Posted by Santiago Gala <sg...@apache.org>.
El mié, 21-02-2007 a las 07:39 -0800, David Sean Taylor escribió:
> I would like to propose an official release date of version 1.0.1 as
> February 27, 2007 (Tuesday)
> I would also like to propose that all feature work complete by today,
> and that only documentation and bug fix work continues thru Monday
> night.
>
I read recently that it does not make sense to cut a release *after*
voting it. Actually, the process they do in httpd and a few other
projects is more like a two phase commit:
- vote a (fuzzy) calendar
- feature freeze, alpha-N or rc-N releases
- once one of the rc-N releases reveals as good enough, it is voted and
becomes the version
The advantages of this strategy is that the committers vote on a
concrete tarball, with all its bugs and, in theory, no surprises. As
only very minor fixes are allowed between rc-N and rc-N+1, it would be
difficult to introduce heavy bugs in the "final" code.
As Roy put it, it only makes sense to vote on concrete code, not on
"intentions to do".
So I'd say, start feature freeze whenever, and repeat a vote when one of
the rc or snapshots seem to be ready to be released.
Regards
Santiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: bridges-dev-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
Re: [VOTE] 1.0.1 Release
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
> I would like to propose an official release date of version 1.0.1 as
> February 27, 2007 (Tuesday)
> I would also like to propose that all feature work complete by today,
> and that only documentation and bug fix work continues thru Monday night.
+1
Note: I've got a few outstanding fixes (all tested and well) to commit.
I'll try to do so this evening, tomorrow the latest.
Ate
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: bridges-dev-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org