[Licq-devel] Proposal for new branch and release strategy

I've done some thinking regarding the branch and release strategy we 
(don't) have and would like to share my thoughts on the problems and 
propose a solution.
Please let me know what you think and fill in any details I might have 
missed.

BR
/Anders


Current situation:
We currently work only in the trunk and we make major changes and break 
plugin API within the same minor release series.
We have no strategy for releasing corrections or important updates on 
short notice. Example 1: when the ICQ login problem appeared last year 
we only released a patch and it took several months before we released a 
real version with the update. Example 2: Licq 1.3.7 had a broken RMS 
plugin, in this case we could release the correction as 1.3.8 but I 
consider it luck that trunk was still relatively unchanged since 1.3.7.
Since 1.3.8 was released, additional bugs have been discovered that I 
would like to release corrections for within the next months, but as 
development in the trunk has resumed I don't know whether a new release 
will be possible or if it will have to be patches this time.
To me it seems that very few people test the release candidates and 
problems aren't found until after the final release is made.

Also, due to technical reasons, Licq versions are limited to 5 digits 
with the following distribution "XX.YY.Z", i.e. whereas major and minor 
versions can go to 99, the release version only goes to 9. To me this 
indicates that the minor version should be stepped (instead of the 
release version) more frequently than we currently do.

Proposed new strategy:
* Normal development continues in trunk as today.
* When it's time for a 1.4.0 release a 1.4-branch is created from the 
current trunk (either from the point of the 1.4.0-RC1 package or some 
time earlier if the trunk is unstable and needs to be stabilized first)
* Bugfixes and other updates for the 1.4.0 release are committed to the 
1.4-branch while development of new features continue in the trunk.
* Additional RCs (if needed) and the final 1.4.0 package are built from 
the 1.4-branch.
* After the release of 1.4.0, the 1.4-branch is kept alive to take 
bugfix commits and is used for building future 1.4.1, 1.4.2, 1.4.3, etc.
* When 1.5.0 is released, bugfixes will go to the 1.5-branch instead.
* Important or critical corrections can still go to the 1.4-branch as 
well (for example if an exploit is found or a protocol update is needed) 
to make additional 1.4.x releases, however this should be a rare event.

Advantages:
* We can release bugfix versions with short notice without having to 
worry about new features or experimental changes in the trunk breaking 
the release.
* We can make pure bugfix releases, which should lead to more stable and 
bug free Licq versions for our users.
* No more code freezes in trunk, development can continue regardless of 
any ongoing releases.

Disadvantages:
* More work for developers as bugfixes needs to be committed or merged 
to both the maintenance branch and the trunk.
* As developers are likely to mostly run the trunk version there is a 
chance that the maintenance branch won't be as well tested between 
releases and faults introduced by the bugfixes aren't caught.


When do we introduce this?
* I suggest that when it's time for the next Licq version to be released 
from the trunk, it becomes version 1.4.0 and starts using the above 
strategy.
* If we want or need to make a 1.3.9 release, a 1.3-branch should be 
created from the 1.3.8 tag and only the relevant corrections be merged 
to it.

Open questions:
* Should we have another branch level to separate major and minor 
versions? (My suggestion is No. It's probably easier to create separate 
working branch when needed for major changes, like was done for cmake, 
instead of having a permanent extra level that needs merges all the time)
* Should we allow minor/simple features to be committed in the 
maintenance branch or keep it strictly to bugfixes? Example of a minor 
feature: Introducing a new keyboard shortcut in the GUI. (I can go 
either way with this one, but plugin API should never change between 
bugfix releases of the same minor version.)
* Should we have a fixed release plan for minor versions? We currently 
release once per year, do we maybe want to change it? (My suggestion is 
to not have fixed dates for the minor versions as it's better to let the 
stability and activity of the trunk decide when it's a good time to 
release.)
* Should we have a fixed release plan for the bugfix releases of each 
minor version? For example: one release every X months until the next 
minor version is released. (I'm leaning towards Yes on this one as it 
allows us to promise bugfixes to be released within a certain time even 
if there are only minor bugs corrected.)
* Should bugfixes be committed first in maintenance branch and then 
merged to trunk or vice versa? (Since I'm unfamiliar with working with 
branches in subversion, I don't know what is the normal strategy.)