[mythtv] Re: LIBVERSION = 0.15.0.99?

Isaac Richards ijr at po.cwru.edu
Sat May 29 15:51:22 EDT 2004


On Saturday 29 May 2004 02:25 pm, Axel Thimm wrote:
> On Sat, May 29, 2004 at 11:31:58AM -0400, Isaac Richards wrote:
> > > > > Uhm, maybe that's exactly why he asked for extra versioning?
> > > >
> > > > No, try reading his email.  He's asking for extra versioning to make
> > > > making up a package name easier for his CVS rpms.
> > >
> > > Well, to be honest Henk is quite right. ;)
> > > http://lists.atrpms.net/pipermail/atrpms-users/2004-May/000486.html
> >
> > That email _still_ says the only reason you want to reuse the libversion
> > for non-binary compatability purposes is to make choosing names for your
> > cvs rpms easier.
>
> I was trying to be diplomatic ;)
>
> > > A 0.14.99 version would have helped, so I'd still propose, if there is
> > > no drawback, to use interim versioning. It doesn't need to be bumbed at
> > > every cvs commit or similar. Probably only need attention at the
> > > beginning and end of a developmeent cycle (e.g. 0.15.0.9 now and
> > > shortly before the next release 0.15.99)
> >
> > I don't see how it will help.  People will then say 'I'm running the
> > 0.14.99 release', and I made no such release.  If they say anything with
> > the word 'release' in there, that shows that they have no understanding
> > that they're running a CVS snapshot that could be unstable, broken,
> > corrupt their DB, etc.
>
> The packages are placed in areas with big warnings signs, e.g.
>
> 	     http://atrpms.net/name/myth-cvs/
>
> It is impossible to not notice the bleeding/experimental status of
> these packages (but you will always find users who will make the
> impossible true, the question is how many these are and if it is worth
> while to tear down CVS package builds to avoid this).
>
> > Why don't you just put 'cvs' in the package name, say they conflict with
> > the normally named packages, and use the date you generated the packages
> > as the version number?
>
> I would have to obsolete "mythtv" with "mythtv-cvs" and vice
> versa. While technically possible it is error prone (all dependencies
> need to be rewritten in the specfiles from "-cvs" to "" and back at
> each switch), and at the end I could be doing more damage than
> good. These obsoletions could be versioned, but then again the issue
> about what version to attach to the cvs builds rises again, so we are
> where we started.

Where we started?  The package name would be:

mythtv-cvs-20040529-1.rhfc1.at

No versioning issues whatsoever.  It's immediately clear when you pulled the 
CVS checkout, and much more useful than some randomly generated version 
string.  The user must install 'mythtv-cvs' instead of just switching to use 
a different repository.  Makes much more sense than meaningless libversion 
increases in the source that needlessly break binary compatability.  

> The best thing would be to maintain an interim version in the sources
> themselves, perhaps 0.14.99cvs.

And that's just not going to happen.  I'm not going to do something the wrong 
way just to make making CVS packages that I already disagree with easier.

Isaac


More information about the mythtv-dev mailing list