Re: [Monotone-devel] Release time

[Ethan Blanton]

Derek Scherger spake unto us the following wisdom:
> > 1) if a release only consists of bug fixes or has small, not BC-breaking
> > improvements (esp. in respect to automate), raise the patch release
> >
> > 2) if a release has bigger improvements or breaks BC, raise the minor
> > version
> >
> > 3) if a major flag day introduces major new things or we've rewritten
> > 90% of monotone (:)), raise the major number.
> >
> >
> I think that pretty much agrees with
> http://apr.apache.org/versioning.htmlwhich is referenced by various
> other projects.

I'd modify this somewhat, for monotone, because *network*
compatability is quite possibly its most visible feature.  Perhaps
something like:

Major version bump -> netsync incompatability (or major features you
                      don't want people to miss)
Minor version bump -> database upgrade required (or ...)
patchlevel         -> bug fixes, minor changes, user can upgrade
                      without concern toward databases or
                      interoperability

This is along the lines of typical library versioning, with minor
versions indicating link-compatible changes, and major versions
requiring relinking.  (The binary compatability prose in the Apache
page above.)

That said, versioning is *way* bikeshed.  Everyone has their own
opinion on how it should be handled.  I think the important thing here
is to pick *something* meaningful and stick to that meaning.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature