Re: tv_grab_pt error 418: I'm a teapot

<[email protected]> Mon, 10 Aug 2015 20:21:01 +0100
Newsgroups gmane.comp.tv.xmltv.general
Message-ID <[email protected]>
On Mon, 10 Aug 2015 19:11:42 +0100, Nick Morrott wrote:
>
> I have to say I'm not a fan *at all* of the appearance of versioning
> individual XMLTV core libraries, especially with versioning that can
> almost match that of the current stable release. E.g.:
 [...]
>
> The XMLTV core libraries are meant to be distributed together as a
> distribution, and are all tied to the version of the core XMLTV.pm
> library at release.
> 
> In addition to providing a maintainance overhead, what is an end-user
> to think if they have version 0.5.65 of a library installed after
> installing 0.5.66 (or later) XMLTV packages?
> 
> If a user ever needs to download an updated version of a specific
> file, you can do this through the Sourceforge code browser by
> downloading the current version of the file as Geoff suggests.
> 
> But I'd much prefer to see users understanding how to actually check
> out the code as a whole from CVS, and configure, make (and optionally
> make install) to ensure they get *all* of the most recent fixes.
> 
> Cheers,
> Nick
 

I'm inclined to agree, but the only issue with *not* versioning is the situation where a user downloads only the (fixed) tv_grab_* script they want and doesn't d/l the associated core library file which has also changed and is needed to run it. They then start reporting problems which are not 'real' because they are using an outdated version of a core lib. (I saw a lot of this when I was working through the bug reports last year.)

Fair enough if people will always d/l and install a complete package build but a lot of people (errr, me included!) only usually update the changed files, not the whole package.

It's complicated by the well known issues with version numbers of the format '0.5.66' failing in certain versions of Perl ('0.005066' is the only safe format).

I have to confess that all the ones like '0.005066' were probably added by me 8-) and were actually selected deliberately to mirror the actual stable release version when they first appeared. (Seems I goofed with Augment.pm =  0.001001 oops.) So version 0.005066 *is* XMLTV 0.5.66. Yes I agree it's misleading when XMLTV then moves on but a core lib still implies the previous release.

The problem arises when a core lib is updated between 'official' releases. We need a way of telling people that a core lib has changed even though a new XMLTV package has not been released. Unless we issue a formal XMLTV release *every* time a core package changes. Which may not be a bad idea!?

Alternatively, perhaps it's simply that XMLTV version itself is wrong: rather than 0.5.66, 0.5.67 etc perhaps 'official' releases should be 0.6.0, 0.7.0. This tracks the major.minor.patch paradigm, and is more representative than what we currently do? If we update (set) the version in all core libs on every official release it then leaves the patch version free to be what it's supposed to be.

Just a thought.

Cheers,
Geoff

------------------------------------------------------------------------------