Re: [Monotone-devel] Release time

[CooSoft Support]

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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>