qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalle Kärkkäinen" <kalle.karkkai...@intstream.fi>
Subject Re: Source management for releases
Date Mon, 23 Jun 2008 09:38:09 GMT

Aidan Skinner:
>          hack  awesome         shiny             bugfix   feature
> trunk ----*-------*-------^-------*-------^---------*---------*----------->
>                       |   |               |
>                    M3.x---*---------------*------------------------------->
>                          fix     |      critfix        |
>                               M3.0                   M3.0
>                                RC1                   FINAL

I'm entering a conversation I've only lurked over, but here goes..

As surely everyone on the list has experienced before, this is a common 
battle between branches and 'the-way-forward'. A balancing act between 
maintenance and new features or even more so balancing a process so that 
it still allows development and does not stagnate to bug fixes.

I'm sure you people have tackled this successully before so I'll be brief.

We have the trunk that continuously goes forward, and from that we 
freeze branches that receive only bugfixes. This would mean that any 
given release (or release candidate) with designated feature set can be 
honed to perfection and the relevant fixes may be applied to the trunk.

But it also allows the trunk to be moving forward with greater speed and 
(possibly) more demanding refactoring work. Of course, in this thinking, 
branches are a one way street, bidirectionality is unwanted as in my 
experience it leads into situations where it's really hard to say what 
patches have been applied to what branches.


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message