"Georg S. Weber" <georgswe...@googlemail.com> writes:
> Thirdly (and most importantly), we could change to a "multispeed"
> approach, i.e. new Sage releases (all the x.y versions, say, and some
> x.y.z with, say, even z) are tested and verified mainly only on the
> main few architecture/systems (the current version and one version
> earlier of Ubuntu, Fedora/Redhat, OS X, and only x86_64 each), with
> binary releases only for those too (!), including the Sage Virtual
> image; followed by (say) Sage releases x.y.1 resp. x.y.'z+1', which
> are then stabilized for the broad variety of the rest of the supported
> architectures and systems. Building myself OS X 10.4 versions for
> years now, I know that people don't complain "too loud" about
> sometimes getting "their" binary release later (or that sometimes an
> entire version is leapfrogged), as long as there is a constant flow of
> updates (although the frequency might be lower).
Please don't do even/odd categorization of minor version numbers. It
doesn't allow you to properly do hotfixes to one or the other, and in
any case, even/odd categorization of any version numbers is confusing
and unintuitive to the user. Here is a nice set of standards for version
numbers (which we by no means are following in any way at the moment):
http://semver.org/
-Keshav
----
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
