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