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?
Paul
- [DISCUSS] A change to our release management Paul Sharples
-