Release/Voting processes

[Nathan Bubna <nb...@gmail.com>]

ok, there seems to be some confusion about the different ways to
prepare, label, and vote on releases.  here's my understanding of the
two most common options.

1) How we used to do it.

    We would put the quality/status of the release in the release
name.  These would typically go something like 1.5-beta1, 1.5-rc1,
1.5.  If a second beta or RC was necessary, then those would end with
a "2".  The proper way to begin this release process is to build the
distribution with the anticipated release name (say 1.5-beta1) and
upload it to where dev@ folks can get it.  This is what i would call
the test build.  Once this test build is available, then call for a
simple +1 (release it), 0 (i'm ambivalent), -1 (don't release) vote.
This is a perfectly valid process, though it has the disadvantage that
the quality/status of the release cannot be changed even if our
opinions of it have changed for better or worse.  If 1.5-rc1 turned
out to have no problems anyone found or cared about, then we would
still have to rebuild a release named 1.5, upload the test build of
it, and then vote to release it, even though the only needed change
was in the name.
   The improper way to do this is to call for a vote before providing
the build for people to test.  Henning initially did this with 1.5,
and i did it for both Veltools 1.3-beta1 and Veltools 1.3-rc1.  That
was the lazy, improper way and won't be done again.  However, for
Henning's second try at 1.5, he did provide a proper test build for us
to download and try before voting.

2) How i'd like to see us to do it.

    We would not put the quality/status of the release in the release
name.   Instead, the release is only given a number (typically in
X.Y.Z form, but there's no reason for that but convention), and the
quality/status of the release is decided by vote and labeled on the
website and not in the release itself.  The proper way to begin this
release process is to build the distribution with the current release
number and upload it to where dev@ folks can get it.  This is, again,
the test build.  Once the test build is available, the release manager
calls for a vote on the quality of the build +1 (GA), +1 (Beta), or +1
(Alpha).  I don't really see much point in have a +1 (RC) option, but
some like it.   Once the vote is over, the release may be made
available with the quality determined clearly labeled on the download
page and in all announcements.   This means that we don't have to do a
new release if an RC is found to be perfect.  All we have to do is
re-vote, change the website, and announce it (if we want).  It also
provides a clear means to demote releases in which serious problems
are later found.  This ease of changing status makes it easier to have
more frequent releases, and helps to ensure that the work of doing a
release is not voided by a -1 vote.  Instead, the quality just gets
lowered, but the release still happens and is available to those who
want it.

We've discussed switching to 2), but i'm not aware of a clear decision
or consensus on that, so it feels like we're still talking about both,
hoping that one or the other will work better for us here.   I really
want to move to 2), but i've seen on other projects that the switch
takes some getting used to.  It may be best if we stick to 1) until
Velocity 1.5 and Veltools 1.3 are out.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org