On 2016-02-26 17:34-0000 Phil Rosenberg wrote: > We have discussed a few API breaking changes recently. Error > reporting, thread safety, C++ API changes and the Fortran API changes > are pretty close to complete by the seems of things. > > Is it time to bring up the possibility of PLPlot 6 again and how we > intend to manage that?
Hi Phil: Good question concerning PLplot 6 which deserves its own subject line. I have noticed there are some large free software projects (e.g., Linux kernel, octave) where they simply make cumulative backwards incompatible changes that are more or less well documented and leave it at that. And that is the model we are currently following right now with PLplot. From my perspective, the big advantage of this model for handling backward-incompatible change is it allows users to slowly adjust to such changes as they occur rather than the alternative of us maintaining strict backwards compatibility at the expense of accumulating huge cruft, and then getting rid of all such cruft in one (likely buggy since so much change is involved) "major release" change that everybody hates! For more on the Linux kernel release history see <https://en.wikipedia.org/wiki/Linux_kernel#Maintenance>. You can see there that they ran to very high "patch" numbers in the 2.6.<patch> series before transitioning to 3.0, and also fairly high "minor" numbers in 3.<minor> before moving to 4.0. In fact, IIRC, there was essentially no difference between 2.6.39 and 3.0.0. In other words the only reason for bumping the major number at that stage was the kernel developers were getting tired of the high patch numbers for 2.6.<patch>, and also I believe they were concerned those "patch" releases were much more than simple bug fixing releases, and moving to kernel 3.0 allowed them to use the patch number for such ("bug-fixing only") releases. The turnover from Linux kernel 3 to 4 had similar "against high version number" motivations rather than introducing a major new feature (see <http://www.zdnet.com/article/linux-kernel-turns-over-release-odometer-to-4-0/>). Actually, PLplot is also following a similar model right now where the release numbers are 5.<minor>.<patch> where I bump just the patch number if there is mostly just bug fixing in the release (e.g., the release of 5.11.1), but I bump the minor number and zero the patch number (e.g., the forthcoming 5.12.0) when there are major developments (e.g., the new Fortran binding) in the release. If we decide to continue this model, then following what was done for the Linux kernel, PLplot 6.0.0 might not be anything special other than a desire on our part to start the minor numbers at zero again. But in my book "12" is not that high, and I would only start worrying about PLplot 6 once we get to PLplot-5.20 or so which will likely be quite a long time from now. In sum, version numbers are fairly arbitrary and each project tends to interpret them in various ways. The above is my interpretation of major, minor, and patch in the PLplot-<major>.<minor>.patch that I release, and I intend to stick with that model. So I plan to use a new minor release version when we introduce the change to no static variables and/or the introduction of an error reporting system. But at some point someone else may take over as PLplot release manager, and they may have their own strong ideas on how to interpret major, minor, and patch in our release numbers. All the above being said, I think regardless of the philosophy of the release manager we should always make it as easy as possible for our users to stick with us through our PLplot-<major>.<minor>.<patch> releases so we should never introduce backwards-incompatible API changes in those releases unless there is a compelling and well-documented motivation (e.g., the cruft-reduction and better consistency of the present Fortran binding changes that I discuss in the 5.12.0 README.release file that is currently being prepared). 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 __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
