One slight deviating point about breaking BC with au stdio... I feel
what ever applications we provide that use it should strive to cope with
BC breakages. E.g. Monotone:AutomateStdio works from 0.35 to the current
release as does mtn-browse which relies on it.
Hopefully though with the changes made recently to stdio, future changes
will be additive :-) (fingers crossed).
Why did I go to this effort? Apart from the obvious it was also because
at work they are on version 0.39 of mtn as any higher breaks the `direct
access to db version of monotone-vis', the later au stdio version of
monotone-viz for some unknown reason runs MUCH slower on our db, too
slow to be of any use :-(. Other companies/people may have similar
issues. And monotone-viz is one of mtn's killer apps...
I like the idea of attaching a specific significance to a change in
major/minor/patch level number. Makes it much clearer for the user.
Tony.
Ethan Blanton wrote:
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
------------------------------------------------------------------------
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel