search

XMLTV / xmltv

Utilities to obtain, generate, and post-process TV listings data in XMLTV format
GNU General Public License v2.0
269 stars 93 forks source link

Identifying versions of tv_grab_uk_tvguide #171

Closed misar1 closed 2 years ago

misar1 commented 2 years ago

Thanks for taking the time to report an issue. Please take a moment to review our open/closed issues above, in case your issue has already been reported.

If you are reporting a new issue, please give your issue a descriptive title and fill out the blanks below, providing as much information as possible.

XMLTV Version? 1.1.1

XMLTV Component? tv_grab_uk_tvguide

What happened? Unable to find a version number or revision date within script.

What did you expect to happen? That it would have either or both.

What steps are needed to reproduce this issue?

xmltv tv_grab_uk_tvguide --version

Any other information?

I noticed the above command in the script and ran it: xmltv tv_grab_uk_tvguide --version Timezone is +0100 XMLTV module version 1.1.1 This is tv_grab_uk_tvguide version 1.1.1

Which looks fine except it produced identical results with both the latest (timezone fix) script and ones I downloaded in December 2021 and January 2022. The only way I can distinguish versions (other than by careful filing) is from the file size (each new version gets a bit larger).

What other software are you using?

Operating System: …Windows 10 21H1

Perl Version: …

garybuhrmaster commented 2 years ago

I do not believe the timezone fixes are yet in a formal release. Did you build your own binary?

misar1 commented 2 years ago

No, I just replaced the script from the formal release. You can find the new one on GitHub (see honir's reply yesterday).

garybuhrmaster commented 2 years ago

I would think that if you manually replace files, you are also going to be required to manually replace/update (in that particular grabber, other grabbers may have other variables) the VERSION variable, as you see fit, as it defaults to the xmltv release version (which is currently 1.1.1). When there is a new xmltv release, the version of xmltv and most grabbers will get automatically updated.

honir commented 2 years ago

Grabbers are not individually versioned but assume their version from the XMLTV release. As garybuhrmaster said, that version is only updated when a formal release is made.

Maybe that is something which could be changed, but in practice there is little need for keeping multiple versions of grabbers. (If you ever need an old version, it is always available from GitHub.)

misar1 commented 2 years ago

You produce regular updates to the script between XMLTV upgrades but I usually only notice them when I come here with an issue. Yesterday I could not remember which script version I was currently running (with XMLTV 1.0.0 which I had also been using w/o problems) and realised the scripts do not include version information.

TBH your scripts are really mini programs (thank you for all your hard work) and in my experience it has always been good software practice to signify even minor updates with a specific version number and/or date. Anyway, in future when I save an updated script I will add its commit date as a comment.

honir commented 2 years ago

I've added a version id to this grabber.

(currently "tv_grab_uk_tvguide 2022-03-29 15:00:00")

NOTE: It does, of course, rely on me remembering to manually update the version details when I commit a new change. So there is no guarantee :-(

misar1 commented 2 years ago

Thanks. I really think it is useful - even if I did suggest it!

honir commented 2 years ago

We used to have them but they caused confusion since people assumed the 'XMLTV version' was the same as that shown by the grabber. So we dropped grabber version ids when we switched from CVS, to GIT (which does not support them anyway).

garybuhrmaster commented 2 years ago

NOTE: It does, of course, rely on me remembering to manually update the version details when I commit a new change. So there is no guarantee :-(

More importantly, it requires each and every person that touches that grabber to remember to change the version comment (not just you). That requires a discipline which may not be common in the project and those who submit pull requests.

garybuhrmaster commented 2 years ago

So we dropped grabber version ids when we switched from CVS, to GIT (which does not support them anyway).

Well, you can have them if you have git commit hooks that every committer is required to have installed and use in exactly the same way.

Git, of course, uses the commit hashes (and git describe) to manage versioning. As it should be.

honir commented 2 years ago

More importantly, it requires each and every person that touches that grabber to remember to change the version comment

This is true, and is why I hesitated. But, on balance, it is causing me more work by people thinking they are running version xx when clearly they are not.

garybuhrmaster commented 2 years ago

This is true, and is why I hesitated. But, on balance, it is causing me more work by people thinking they are running version xx when clearly they are not.

Or, you could have released a xmltv 1.1.2 (using semantic versioning, that would have implied a patch, which this was, and I would have nominally recommended, but that is mostly because I don't have to write and post the announcement of the release).

honir commented 2 years ago

...or test all the repo builds, or rebuild the win exe ;)

If this bug had an ongoing impact then I would probably have suggested a new patch release. However the impact of this bug is now 'over' until same time next year (it only affects programmes occuring during the 1-hour clocks-foward window.). Not worth the effort of a patch release just for that IMO. (I'm sure there'll be other opportunities before March 2023.)

Perhaps we need to make the patch release process easier/more automated? But that's a discussion for another place.