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 ;)
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
