Release candidates / process (Was: Re: Image Versions (Re: Trunk image size))

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Release candidates / process (Was: Re: Image Versions (Re: Trunk image size))

Casey Ransberger
I'd like to suggest:

Prior to release, a release candidate *image* is cut. Only bug fixes
go into this, and would also be applied to the trunk.

This is a pretty common agile tactic which allows releases to
stabilize without ever halting development on the mainline.

Have cake and eat too!!!! Just make a copy of the cake before you eat it. :)

On Friday, December 11, 2009, K. K. Subramaniam <[hidden email]> wrote:

> On Friday 11 December 2009 08:04:14 pm Bert Freudenberg wrote:
>> IMHO instead of branching for release we should do a feature freeze and
>>  code freeze, maybe for 2 weeks, call the result a release, and then
>>  continue the happy hacking. Otherwise the burden of releasing again falls
>>  onto too few people. We should all be working towards a release together.
>>  The actual releasing would take nothing more than packaging and uploading.
> Sure.  We could have a short 'cool down' period when the  trunk is frozen. . A
> release is much more than packaging and uploading. People will need time to
> cleanup image, take screenshots and screencasts for documentation, update
> documents and websites, post announcements, blogs etc.
>
> Just so that the pace doesn't slacken, The Freeze can be kept short (say no
> more than two weeks) and well-spaced (say no more than four freezes in a
> year).
>
> Now back to the topic of image versioning :-).
>
> Subbu
>
>

--
Ron

Reply | Threaded
Open this post in threaded view
|

Re: Release candidates / process (Was: Re: Image Versions (Re: Trunk image size))

Bert Freudenberg
On 12.12.2009, at 01:06, Ronald Spengler wrote:
>
> I'd like to suggest:
>
> Prior to release, a release candidate *image* is cut. Only bug fixes
> go into this, and would also be applied to the trunk.
>
> This is a pretty common agile tactic which allows releases to
> stabilize without ever halting development on the mainline.

IMHO that tactic would only be advantageous in larger teams. In our case we can't effort to split. If hacking continues on the mainline, who do you think will work on the release branch? Are you volunteering? (*)

With a (reasonably short) freeze, everybody should be eager to help getting the release out of the door, so they can get back to the fun hacking. Everybody is testing. Everyone fixes bugs, and only bugs.

IMHO "halting (feature) development on the mainline" would be a Good Thing.

- Bert -

(*) That's a rhetoric question. We don't want to put the development effort on a too small release team again.