On Fri, 1 Dec 2006, Rainer Klute wrote:
However, a beta should be only a step on the way to a full release. This
is something we really need to have. There are probably many users out
there who don't trust in any beta or alpha releases - not to speak about
a nighly build. They just grab the latest full release and use that. How
many years have passed since we release it? We really need one!
I think the question should be:
* should we do a release now, freeze, work to a release now, release with
some HSLF apis that are about to change, without excel comment support
etc, then do another release in the new year once we have that code?
or
* alpha/beta now, beta when we've got the HSLF api tweaks + excel comment
support in the new year, then freeze and release then?
My main reason for suggesting an alpha was the HSLF api tweaks. If we're
happy with doing a release where we're planning to change some (admitedly
scratchpad) APIs just after, then I don't see why we can't then move to a
speedy release.
As for the freeze, once we've done this release (be it alpha or beta), we
can do an SVN branch for the release candidate (if we decide we want one
now). That can be frozen, and all bug fixes applied to it and trunk (new
work only to trunk). The final release can be from there.
I think that whatever happens, we should do a release in a few days time
(be it alpha or beta, based on voting). Between now and then, we should
decide if we want this to flow straight into a release candidate process
(for a -final in late December / early January), with another -final once
we have comments support etc, or if we want to hold off the -final until
we have that code in.
I'm not too bothered either way, but then I tend to use nightlies in
production :) Do other people want to weigh in?
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
