You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Nick Burch <ni...@torchbox.com> on 2006/12/13 13:46:42 UTC

[vote] timescale and involvement for 3.0-final release process

Hi All

Now we've got the release of alpha 3 out of the way, it's time to decide 
on when we should start on the 3.0 final release process.

There seems to be two different opinions on this, which hopefully I've 
captured in my options below. If not, please let me know :)


Basically, we need to decide when to start the release process (which will 
involve a feature freeze on that branch, with it only accepting bug 
fixes), and check that we have enough volunteers to help with the bug 
identification / fixing / testing for that timescale.

So, it would be great if everyone could say which proposed timescale they 
prefer, and which timescale(s) they would be available to help over.


[option 1]
   We should fork a 3.0 release branch as soon as the vote is over. We will
    work on bug fixes for it (also applied to TRUNK) over christmas and the
    new year, with a view to releasing 3.0-Final in early January.
   We will then have a 3.1 release once the excel comment stuff, and HSLF
    changes have gone in (expected to be by march/april)
   (We will aim for 3.2 about 6 months later)

[option 2]
   We should wait for the excel comment support, and HSLF changes. Once
    they are in (expected to be by march/april), we will fork a 3.0 release
    branch. We will work on bug fixes for it (also applied to TRUNK), with
    a view to releasing 3.0-Final not long after.
   (We will aim for 3.1 about 6 months later)

[option 0]
   I don't mind when we do a release, but we should probably do one
[option -1]
   I don't think we should have a release any time soon

[bug-fix-1]
   I commit to spending some time fixing bugs over christmas and the new
    year, to support an [option 1] style release
[bug-fix-2]
   I commit to spending some time fixing bugs in march/april, to support
    an [option 2] style release

[bug-test-1]
   I commit to spending some time identifying and reporting bugs, and
    testing fixes to them, over christmas and the new year, to support an
    [option 1] style release
[bug-test-2]
   I commit to spending some time identifying and reporting bugs, and
    testing fixes to them, in march/april, to support an [option 2] style
    release


Voting will last 1 week. Assuming the release timescale with the most 
votes has enough people to support a release process, we'll go with that. 
Otherwise, we'll just have to go with the release timescale that the most 
people are available to support.

Oh, and there will be another vote before we actually do the release, to 
check everyone's happy for it to go out in its then form.

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/


Re: [vote] timescale and involvement for 3.0-final release process

Posted by Yegor Kozlov <ye...@dinom.ru>.
I'm working on cell comments right now. It should be ready in two
weeks. Any objections to [option 1] + cell comments?

Regards,
Yegor

NB> Hi All

NB> Now we've got the release of alpha 3 out of the way, it's time to decide 
NB> on when we should start on the 3.0 final release process.

NB> There seems to be two different opinions on this, which hopefully I've 
NB> captured in my options below. If not, please let me know :)


NB> Basically, we need to decide when to start the release process (which will 
NB> involve a feature freeze on that branch, with it only accepting bug 
NB> fixes), and check that we have enough volunteers to help with the bug 
NB> identification / fixing / testing for that timescale.

NB> So, it would be great if everyone could say which proposed timescale they 
NB> prefer, and which timescale(s) they would be available to help over.


NB> [option 1]
NB>    We should fork a 3.0 release branch as soon as the vote is over. We will
NB>     work on bug fixes for it (also applied to TRUNK) over christmas and the
NB>     new year, with a view to releasing 3.0-Final in early January.
NB>    We will then have a 3.1 release once the excel comment stuff, and HSLF
NB>     changes have gone in (expected to be by march/april)
NB>    (We will aim for 3.2 about 6 months later)

NB> [option 2]
NB>    We should wait for the excel comment support, and HSLF changes. Once
NB>     they are in (expected to be by march/april), we will fork a 3.0 release
NB>     branch. We will work on bug fixes for it (also applied to TRUNK), with
NB>     a view to releasing 3.0-Final not long after.
NB>    (We will aim for 3.1 about 6 months later)

NB> [option 0]
NB>    I don't mind when we do a release, but we should probably do one
NB> [option -1]
NB>    I don't think we should have a release any time soon

NB> [bug-fix-1]
NB>    I commit to spending some time fixing bugs over christmas and the new
NB>     year, to support an [option 1] style release
NB> [bug-fix-2]
NB>    I commit to spending some time fixing bugs in march/april, to support
NB>     an [option 2] style release

NB> [bug-test-1]
NB>    I commit to spending some time identifying and reporting bugs, and
NB>     testing fixes to them, over christmas and the new year, to support an
NB>     [option 1] style release
NB> [bug-test-2]
NB>    I commit to spending some time identifying and reporting bugs, and
NB>     testing fixes to them, in march/april, to support an [option 2] style
NB>     release


NB> Voting will last 1 week. Assuming the release timescale with the most 
NB> votes has enough people to support a release process, we'll go with that. 
NB> Otherwise, we'll just have to go with the release timescale that the most 
NB> people are available to support.

NB> Oh, and there will be another vote before we actually do the release, to 
NB> check everyone's happy for it to go out in its then form.

NB> Nick

NB> ---------------------------------------------------------------------
NB> To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
NB> Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
NB> The Apache Jakarta POI Project: http://jakarta.apache.org/poi/


---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/


Re: [vote] timescale and involvement for 3.0-final release process

Posted by Nick Burch <ni...@torchbox.com>.
My vote is:
   [option 2]

And I agree to help for both of:
   [bug-fix-1]
   [bug-fix-2]

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/