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