Robert Burrell Donkin ha scritto:
On Mon, May 5, 2008 at 4:00 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Can you say it again with different words? (concrete checklist/roadmap
would be perfect to avoid my misunderstanding ;-) ).
1 Isn't it time we did a release?
2 [PROPOSAL] Prepare release foo-x.y.z managed by Anne
3 Focus on fixing code base
4 Anne tags then prepares foo-x.y.z which is the release candidate and
makes it available for proving
5 [VOTE] Promote foo-x.y.z to alpha
6 [VOTE] Promote foo-x.y.z to beta
7 [VOTE] Promote foo-x.y.z to fc
if foo-x.y proves to be substandard then start again with foo-x.y.(z+1)
So we simply do what we did for previous releases but each release will
require multiple votes to define increasing quality levels, right? This
way we don't require the quality to be FC at the first call.
Makes sense.
We did something similar with jSPF. it was 0.9.4 unstable, 0.9.5
unstable, 0.9.6 was stable so we had 0.9.6 declared as stable in the
website.
So first we tag and release and then we decide what "quality label" to
use to describe that release using a vote for each "quality step".
I will not be Anne (because Anne is a girl ;-) ), but I would be happy
to test/fix during #3 and to write my votes in #1,#2,#5,#6 and #7.
IMHO #1 answer is an implicit YES for every source tree not having had a
release in the last year.
The only thing I don't like of this approach is that if we tag before we
decide the quality level we cannot include the quality label in the
release file name (and artifacts deployed to the maven repository), but
maybe this "missing information" worth the advantages of having a much
easier entry level for releasing something.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
