Proposal for new branch and release strategy
Anders Olofsson
(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.)
Erik Johansson
On Tue, Dec 29, 2009 at 12:36, Anders Olofsson <fl...@licq.org> wrote:
> 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)
I like the way trac names there branches and would like to propose
1.4-stable as the branch name.
> 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.
I think we should start right away and create a 1.3-stable branch. But
not from the tag, but rather from the revision on trunk where the tag
was created from.
Why you may ask. The reason for this is how I designed the create-tag
script. The tag it creates is laid out in the same way as the tarball.
This way you can check out the tag and it will look exactly as the
tarball, directory structure and contents. I don't think we should do
this way any more. To make it simple to merge between release branches
and trunk, they should have the same layout.
Suggestion:
1. Create /branches/1.3-stable from trunk r6900.
2. Move /trunk/{scripts,vendor,website} to / since they are not part
of the "core" and don't need a trunk/branches/tags layout.
3. Remove (or move to /branches) jons-gtk-gui and jons-gtk2-gui since
they are not included in the releases.
4. From now on, to tag, do "svn cp <url>/trunk (or 1.3-stable)
<url>/tags/1.3.9".
5. Update the create-tarball script to handle creating tarballs from a
branch or tag.
6. Remove the create-tag script.
I volunteer to do this if it is agreed upon.
> 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)
Agree with no.
> * 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.)
I think minor features are ok.
> * 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.)
Agree.
> * 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.)
Since it takes some work to do a release I don't think we should
overcommit us. With your proposed scheme I think it will be easier to
decided when to do releases based on the severity of the bug(s).
Perhaps we can leave this at no for the time being and see how it
plays out?
> * 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.)
I think we should commit it to trunk first if possible and then
"backport" it to the release branch.
// Erik
--
Erik Johansson
Home Page: http://ejohansson.se/
PGP Key: http://ejohansson.se/erik.asc
Erik Johansson
> 1. Create /branches/1.3-stable from trunk r6900.
Done.
> 2. Move /trunk/{scripts,vendor,website} to / since they are not part
> of the "core" and don't need a trunk/branches/tags layout.
Done.
> 3. Remove (or move to /branches) jons-gtk-gui and jons-gtk2-gui since
> they are not included in the releases.
They have been removed.
> 5. Update the create-tarball script to handle creating tarballs from a
> branch or tag.
Done.
To create a tarball from the 1.3-stable branch, run e.g.
"create-licq-tarball.sh -b -d 1.3-stable". To create the release
tarball (from a tag), run e.g. "create-licq-tarball.sh -b -g -s -t
licq-1.3.9 -n licq-1.3.9". See --help for more info.
The script has also gotten the feature that when exporting a branch or
trunk (not tag), the extra version will be set to the exported
revision, just as is done when building from a checked out copy.
Should be useful for the nightly exports.
> 6. Remove the create-tag script.
Done. To tag a release now, simply use svn cp.