Hi Tom:

On 2016-09-22 13:54+0100 Tom Schoonjans wrote:

> In the scenario I am suggesting, you would just end up with a new
branch that starts at a tag and will contain bug fixes only. It will
never need to be merged into master as it will consist of commits that
were cherrypicked from master.

> This kind of workflow is used for example by all GNOME projects such
as glib and gtk+: development occurs on master, when a new major
release is ready, a tag is created (e.g. 3.22.0), as well as a new
branch with the name of that major release (gtk-3-22), which will then
receive bug fixes that were cherrypicked from master, but not its new
features! Every now and then maintenance releases will be created off
this branch like 3.22.1, 3.22.2 etc.

This is certainly a possible approach, but in my view an even better
(and simpler) approach would be to get out our releases (whether
maintenance releases or otherwise) in a timely manner, i.e., every 3-6
months.  I have obviously fallen short of that goal for this release,
but I also hope to do a lot better moving forward!

Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).

Linux-powered Science

Plplot-general mailing list

Reply via email to