On 1 Nov 2011, at 10:19, 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? > > Paul
I like all of these ideas - for 6/7 I think we can just keeping upping the tempo for each release to a rate that works for us. Definitely we should release more frequently, with fewer issues attached to each release.
