[mythtv] LIBVERSION = 0.15.0.99?

[Isaac Richards]

On Saturday 29 May 2004 02:41 am, Bruce Markey wrote:
> Isaac Richards wrote:
> > On Saturday 29 May 2004 02:08 am, Axel Thimm wrote:
> >>Hi,
> >>
> >>would it be possible to have an interim versioning scheme? This is
> >>useful for packaging CVS versions w/o possibly breaking upgrade
> >>paths. For packaging CVS versions one must either choose the latest
> >>release (e.g. 0.15) or guess what the next could be (0.15.1? 0.16?).
> >>
> >>Both methods have its drawbacks, the former is version-safe, but may
> >>indicate CVS _before_ 0.15 and not after, and the latter is guesswork
> >>which will break at some time.
> >>
> >>So it would be nice to have an interim versioning (e.g. 0.15.0.99
> >>leaving space for a .1 release, or right to 0.15.99 perhaps), if this
> >>is not disturbing in any way.
> >
> > The libversion changes when the library changes in an incompatible way,
> > not before.
> >
> > Also, I'm having second thoughts about you packing CVS versions -- check
> > the users list about people insisting they're running 0.15 when they're
> > using a CVS package of yours from 3 weeks ago.
>
> Isaac, I should have mentioned this the other day but might it
> be good practice to bump the MYTH_BINARY_VERSION date when
> tagging a version (or right before that last test compile)?
> Might give some clue if a binary is post-release.

Why bump the binary version if the binaries are compatible?  The only reason 
that string exists in libmyth is to ease binary compatability problems across 
things that use libmyth (no more 'did you do a 'make distclean?' emails on 
the mailing list), and changing it when not necessary kinda defeats the 
purpose.  It really shouldn't be printed out on startup, as it's not a real 
version string.

I'm certainly not going to change the lib version for 0.15.1 as then people 
can only replace the mythtv libs/binaries, and not have to get new plugins as 
well.

Isaac