[mythtv] Re: LIBVERSION = 0.15.0.99?

[Axel Thimm]

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.

Also note that the cvs versions were tagged as such in the package
full name (which includes version/release tags), and is it quite
difficult to query for the version of a package without seeing the
attached release tag.

For example the last mythtv cvs rpm was called

# rpm -q mythtv
mythtv-0.15-70cvs.rhfc1.at

The same users that chose to ignore this will also ignore
mythtv-cvs-0.15-70.rhfc1.at.

The usual way in packaging is to invent an intermediate version or
guess the next version. It is better to coordinate this with the
authors, which is why I brought this up here.

The best thing would be to maintain an interim version in the sources
themselves, perhaps 0.14.99cvs. Next to that comes a canonicalization
of CVS versioning for packaging (both rpms and debs), e.g. you say you
wish the CVS versions to be <next version>-0.01"cvs", e.g. like above.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20040529/d9c57d0a/attachment.pgp