You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2010/02/01 23:08:06 UTC
2.0.0 release schedule proposal
Hi all,
I'd like to make a number of "proposals" here for a release schedule.
Please comment and/or vote +- on each one of the items below.
Thanks,
-- leif
1. Feature freeze for 2.0.0 is 2/22 2010. Features that have not been
committed before this date will not make it into the 2.0.0
release. We create the 2.0.0 release branch on this day, and trunk
should be considered frozen the entire day (or until we declare it
open again on the mailing list).
2. We start preparing for an alpha release, following the release
management guidelines
(http://incubator.apache.org/guides/releasemanagement.html). This
includes the PPMC voting on the release, and bring it to IPMC for
voting as well. This might take several iterations until we get a
release approved, so we can't schedule much beyond this. Any bugs
filed to pass the IPMC release approval will obviously have to be
fixed on both 2.0 release and trunk.
3. On 2/23 2010, trunk is considered open for development again. John
and George can start merging dev branch to trunk at their
convenience now.
There are a number of steps for us to "resolve" in that guideline above,
including the format of the STATUS file, and how to branch Paul
suggested we do the branching and tagging like copy trunk to
branches/2.0.x, then copy branches/2.0.x to tags/2.0.0. The release
process above also has major dependencies on us closing all the bugs
related to release, including RAT reports, any incompatible licenses and
the TM issue.
Re: 2.0.0 release schedule proposal
Posted by Leif Hedstrom <le...@ogre.com>.
On 02/01/2010 05:42 PM, Nick Kew wrote:
>
> No votes yet, but +1 on taking a direction that can lead to release.
> It would be good to see the trunk-vs-dev issue sorted at the same
> time, so people like me know where to start from when hacking on
> the edges of the code or contributing patches.
>
Yes, me too. The goal (I hope) is to merge dev branch back to trunk as
soon as possible.
>
> Feature freeze is more commonly associated with commercial
> software than with Apache. No problem with using it if
> people are happy working to it, but if anyone thinks there
> should be no feature freeze, that's at least a legitimate
> topic for debate.
>
The worry is that we'd get untested new features onto an otherwise
stable (hopefully) release. But, good to know, and I definitely is not
biased either way, but I'm pretty sure we'll need to have some
guidelines for making sure a release is cut from a trunk that is stable.
> More important IMHO is an API/ABI promise: third-party developers
> should be assured that a plugin developed for 2.0.0 will work
> for future 2.0.x, preferably without a need to recompile.
> If there is no such promise, you need to make it clear.
>
Definitely, 2.0.x will be ABI compatible.
Cheers!
-- leif
Re: 2.0.0 release schedule proposal
Posted by Nick Kew <ni...@apache.org>.
On Mon, 01 Feb 2010 15:08:06 -0700
Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I'd like to make a number of "proposals" here for a release schedule.
> Please comment and/or vote +- on each one of the items below.
No votes yet, but +1 on taking a direction that can lead to release.
It would be good to see the trunk-vs-dev issue sorted at the same
time, so people like me know where to start from when hacking on
the edges of the code or contributing patches.
Comments just to challenge your assumptions, just in case
they provoke thought in anyone here.
> Thanks,
>
> -- leif
>
> 1. Feature freeze for 2.0.0 is
Feature freeze is more commonly associated with commercial
software than with Apache. No problem with using it if
people are happy working to it, but if anyone thinks there
should be no feature freeze, that's at least a legitimate
topic for debate.
More important IMHO is an API/ABI promise: third-party developers
should be assured that a plugin developed for 2.0.0 will work
for future 2.0.x, preferably without a need to recompile.
If there is no such promise, you need to make it clear.
This is just IMHO, not seeking to lay down the law :)
--
Nick Kew
Re: 2.0.0 release schedule proposal
Posted by Leif Hedstrom <zw...@apache.org>.
On 02/01/2010 06:09 PM, John Plevyak wrote:
> +1, though I would like to see the list of features
> we want/anticipate for 2.0.0 and maybe some names
> (particularly if I am on that list :)
>
I don't think you are on the hook for any of them, but feel free to look
at that Jira list :
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310963&fixfor=12314343
tFeel free to add / delete to this (or to 2.1 version). I'd like to use
the Jira "target" version help produce bug triage lists for releases,
since it's really easy to produce this directly from the Jira "main" TS
page.
There are still a bunch of Yahoo features / fixes that Y! would like in
the 2.0.0 release, but, IMO at least, we need to put a deadline for
this. That's where that 2/22 "freeze" comes from.
I'll ask Miles to work with the internal Y! team to produce a Wiki page
with the patches that we can expect to see in the near future.
Cheers!
-- leif
Re: 2.0.0 release schedule proposal
Posted by John Plevyak <jp...@acm.org>.
+1, though I would like to see the list of features
we want/anticipate for 2.0.0 and maybe some names
(particularly if I am on that list :)
john
On 2/1/2010 2:08 PM, Leif Hedstrom wrote:
> Hi all,
>
> I'd like to make a number of "proposals" here for a release schedule.
> Please comment and/or vote +- on each one of the items below.
>
> Thanks,
>
> -- leif
>
> 1. Feature freeze for 2.0.0 is 2/22 2010. Features that have not been
> committed before this date will not make it into the 2.0.0
> release. We create the 2.0.0 release branch on this day, and trunk
> should be considered frozen the entire day (or until we declare it
> open again on the mailing list).
> 2. We start preparing for an alpha release, following the release
> management guidelines
> (http://incubator.apache.org/guides/releasemanagement.html). This
> includes the PPMC voting on the release, and bring it to IPMC for
> voting as well. This might take several iterations until we get a
> release approved, so we can't schedule much beyond this. Any bugs
> filed to pass the IPMC release approval will obviously have to be
> fixed on both 2.0 release and trunk.
> 3. On 2/23 2010, trunk is considered open for development again. John
> and George can start merging dev branch to trunk at their
> convenience now.
>
>
> There are a number of steps for us to "resolve" in that guideline above,
> including the format of the STATUS file, and how to branch Paul
> suggested we do the branching and tagging like copy trunk to
> branches/2.0.x, then copy branches/2.0.x to tags/2.0.0. The release
> process above also has major dependencies on us closing all the bugs
> related to release, including RAT reports, any incompatible licenses and
> the TM issue.
>
>
Re: 2.0.0 release schedule proposal
Posted by George Paul <ge...@apache.org>.
+1 on all 3 items. I've gone through the current 2.0.0 issues/features
list on Jira and signed up for the ones I can commit to currently.
-George
On 2/1/10 2:08 PM, Leif Hedstrom wrote:
> Hi all,
>
> I'd like to make a number of "proposals" here for a release schedule.
> Please comment and/or vote +- on each one of the items below.
>
> Thanks,
>
> -- leif
>
> 1. Feature freeze for 2.0.0 is 2/22 2010. Features that have not been
> committed before this date will not make it into the 2.0.0
> release. We create the 2.0.0 release branch on this day, and trunk
> should be considered frozen the entire day (or until we declare it
> open again on the mailing list).
> 2. We start preparing for an alpha release, following the release
> management guidelines
> (http://incubator.apache.org/guides/releasemanagement.html). This
> includes the PPMC voting on the release, and bring it to IPMC for
> voting as well. This might take several iterations until we get a
> release approved, so we can't schedule much beyond this. Any bugs
> filed to pass the IPMC release approval will obviously have to be
> fixed on both 2.0 release and trunk.
> 3. On 2/23 2010, trunk is considered open for development again. John
> and George can start merging dev branch to trunk at their
> convenience now.
>
>
> There are a number of steps for us to "resolve" in that guideline above,
> including the format of the STATUS file, and how to branch Paul
> suggested we do the branching and tagging like copy trunk to
> branches/2.0.x, then copy branches/2.0.x to tags/2.0.0. The release
> process above also has major dependencies on us closing all the bugs
> related to release, including RAT reports, any incompatible licenses and
> the TM issue.
>
>