I agree with most (all?) of what you wrote. Some comments below.
On Tue, Dec 29, 2009 at 12:36, Anders Olofsson <[email protected]> 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
