On Fri, Apr 15, 2016 at 4:19 PM, Ralf Stephan <gtrw...@gmail.com> wrote: > Once there is a consensus about what the Sage core consists of, what you > then want > is a way to signal developers downstream that > > * "this new revision of the Sage core does not change its interface" > * "this new revision of the Sage core has (backwards-compatible) additions > to its interface" > * "this new revision of the Sage core removes parts of its interface" > > Sounds familiar? Linux shared libraries use major/minor/micro version > numbers > to load the newest still compatible version via libtool. The library > developers just > need to take care to apply a specific version increment scheme. See e.g. > http://www.freesoftwaremagazine.com/articles/building_shared_libraries_once_usi > ng_autotools (the part about "The Libtool library versioning scheme" has > comparisons > between different numbering schemes). > > What I'm proposing is to apply such a scheme to allow clear signalling of > changes > that were done in the newest Sage core version vs the earlier ones. This > presupposes > of course that the core is defined.
Great point--in addition to what may or may not need to be done with the sage library itself, switching to a reliable version scheme is perhaps even more important--a prerequisite to anything else. Thanks, Erik -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
