Hi Phil:

On 2018-12-18 00:33-0000 Phil Rosenberg wrote:

Sounds like a generally good plan to me.

Good.

The only issues might be picking what is a bug fix commit vs a non
  bug fix commit - I'm sure we are all guilty of finding a bug while
  changing code and not submitting it as a separate commit. But
  providing we all try to be good in that sense, I think a bug fixes
  release is a good idea.

The other important issue is whether the bug is a regression or not.
Regressions mean by definition that users of prior versions of PLplot
are going to get a nasty surprise by the new version of PLplot.  So
avoidance of regressions is my motivation for asking for comprehensive
testing on all platforms prior to each release, and anytime such
a regression is turned up by such testing, I view it as release critical,
i.e., the release should be held until a proper fix for the regression
has been implemented.  However, if a regression actually gets into a
release despite our testing efforts, then that would be a large
motivation to immediately issue a bug-fix release containing the
fix for that regression.

But I would rather not learn about the git steps needed for a bug-fix
release under such time pressure, and the present bug fix has a wide
impact for all our present or future qt device users.  So I am going
to use the present impactful bug fix as a good excuse to get educated
on the git steps needed to create a bug-fix release.  However, I will
likely not be willing to do this again unless the bug fix is actually
a fix for a regression.  Instead, I would like to spend most of my
PLplot effort on development and making sure that our regular releases
(which normally include both bug fixes and new development) occur
every 6 months or less.  Due to a variety of excuses I haven't managed
to do that recently, but I am planning on having a much better
ordinary release outcome in the latter part of the first half of 2019.

Alan
__________________________
Alan W. Irwin

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-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to