On 01/11/2011 11:31, Ate Douma wrote:
On 11/01/2011 11:19 AM, Paul Sharples wrote:
Hi all,
I thought I'd put together some thoughts on our current release
management,
after a few conversations I have had off list. As I am sure you are
all aware, I
originally created a branch for a release, I then made the artifacts
from this
branch and started the vote thread. (I subsequently made further
'release
candidates' from this branch if the original vote failed). However,
this is not
the ideal method of putting builds out (for a number of reasons) For
example -
having to port fixes back to the branch from the trunk. (This
happened twice
with version 0.9.1 and 0.9.0)
From now on and starting from the 0.9.2 build I suggest to do it
differently. I
plan to tag the trunk when we want to make a release and then create
the build
artifacts from that. This means that...
(1) Getting ready for a build I would update all the property files
in the
trunk, removing any -SNAPSHOT references. For example I would update
the current
trunk property files from '0.9.2-incubating-SNAPSHOT' to read
'0.9.2-incubating'
(2) The trunk would be tagged and after that, the trunk version moves
on by one.
For example for next build I would create a '0.9.2-incubating' tag.
The trunk
property files would subsequently be set to '0.9.3-incubating-SNAPSHOT'.
(3) If a vote fails, we move onto the next version no matter what.
For example
the next one being' 0.9.2-incubating', if that vote fails then we
move onto
'0.9.3-incubating' as the next release. The trunk will now probably
be set to'
0.9.3-incubating-SNAPSHOT' anyway. (this means that sometimes we may
skip a
version because the vote failed)
(4) Tagged versions of code are not modified and will only be used to
build
artifacts from.
(5) We will no longer have Release Candidate versions. i.e.
0.9.1-RC1, 0.9.1-RC2.
(6) We need to re-jig our JIRA issue management. We originally had
lots & lots
of issues per version. As we are a small project (in terms of
commiters) we need
to spread out issues so that we can get the tasks done and be able to
make
releases more often.
(7) I believe RAVE, for example releases about once a month - do we
also want to
release that often, or is it better to do it every 6 weeks or every
two months
for us?
(8) Releasing more builds, more often means we are (possibly) going
to get to
version 1.0 a lot quicker.
thoughts?
I'm very much in favor of 1-5.
Note that this 'process' is something Maven is particular 'good' at,
e.g. can do this almost fully automated... (just two or three simple
commands to execute and you're 'done'). As well as automate lots of
the 'other' issues concerning tagging/releasing like standardizing and
ensuring the process of bundling the correct LICENSE/NOTICE files ;)
Our release process is pretty much automated now using ant/ivy.
(although I guess still not quite as slick as using maven) It's been
getting it to that stage which has been the problem. (i.e deploying
different licence/notice files for each of the particular builds & also
figuring out how to write complete ant/ivy tasks for deploying/signing
builds & doing the same with maven artifacts.) I'm not quite ready to
abandon it just yet. However, it seems the apache process for
releasing *anything* seems more geared towards using maven, rather then
ant/ivy (the documentation is better for doing things the 'maven' way).
I think at some point we should examine the possibility of moving over
to maven for our build process.
The latest problem with the NOTICE file not being correct is due to
building artifacts from the branch, which after 3 or 4 cycles had an out
of sync NOTICE file with the trunk version, my bad :-(
Paul
Concerning 7) I have no strong opinion, but typically the shorter the
cycle the more you are 'forced' to break large scale features up into
more manageable chunks. Which in general is 'a good thing' imo, easier
for others to chime in (so also good community wise), better to
review/validate. And protects against those 'in process' features
which never seem to complete but everyone is 'waiting' on... causing a
lock on progress in general.
About 8) that might be true or not, I don't think it automatically
will speed up getting to a 1.0 version. But it likely will help :)
Ate
Paul
