Hi Alan,
Releasing regularly new versions of the package is always good: it instills confidence in users that they are using a software package that is being actively developed and maintained. However, I do think that the approach of having bug-fix branches is essential when making regular releases (3-6 months). Implementing new features (like the new Fortran bindings you mentioned) can take a long time, and it is difficult to predict when a new feature is ready to ship. After all, I am assuming none of the core developers are working full-time on PLplot right? This way of working unfortunately leads to large gaps between releases, which has led to the current situation where PLplot cannot be compiled with the latest version of CMake. Having a bug fix branch, and making releases off it, would ensure that PLplot can quickly address incompatible changes in its dependencies, or just fix important bugs, while relieving the developers from the pressure of having to produce a new release that will be a mixture of (hopefully properly working) new features and bug fixes. Best, Tom > On 22 Sep 2016, at 20:01, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > 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
