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 __________________________ 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 Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
