[DISCUSS] A change to our release management

[Paul Sharples <p....@bolton.ac.uk>]

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

Re: [DISCUSS] A change to our release management

[Paul Sharples <p....@bolton.ac.uk>]

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

Re: [DISCUSS] A change to our release management

[Ate Douma <at...@douma.nu>]

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

Re: [DISCUSS] A change to our release management

[Scott Wilson <sc...@gmail.com>]

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.