search

PhilterPaper / Perl-PDF-Builder

Extended version of the popular PDF::API2 Perl-based PDF library for creating, reading, and modifying PDF documents
https://www.catskilltech.com/FreeSW/product/PDF%2DBuilder/title/PDF%3A%3ABuilder/freeSW_full
Other
6 stars 7 forks source link

$LAST_UPDATE #155

Closed PhilterPaper closed 3 years ago

PhilterPaper commented 3 years ago

I also set $LAST_UPDATE (the last release in which a file was changed, which could be earlier, but never later, than $VERSION) in PDF::Table. The idea is that you can see how long ago this file last changed, and whether you might have missed an update (i.e., be running an old version of the file, although comparing it to $VERSION isn't going to tell you anything -- you might have to compare to a known "latest" version's LAST_UPDATE). It was more for my internal bookkeeping than anything else (which is why I used my rather than our). I had a suggestion from someone that they would like to see it as our rather than my.

BTW: I don't know if having $LAST_UPDATE is common practice. But, shouldn't it be our, so testcode can check it from outside to test that you really have the right thing in your PERL5LIB?

Would our $LAST_UPDATE = 'x.x.x'; be more useful to others? Would it interfere in any way with how other "our" variables are handled? Do any other packages use $LAST_UPDATE to mean something different? Note that PDF::Table is one file (Table.pm), while PDF::Builder has hundreds of files, each with potentially a different last update. Basically, it tells you whether a file was updated with this release, or not. Knowing the last update on Builder.pm (or Table.pm) might be the most useful, if the version isn't useful for that.

I would like to just modify the build process to change "my $LAST_UPDATE" to "our $LAST_UPDATE" on the fly, rather than editing all the files. If you have a use for $LAST_UPDATE, would it be useful to see our in GitHub, rather than in just the final release?

carygravel commented 3 years ago

$LAST_UPDATE is not common practice, AFAIK, and is in any case redundant you can automatically check the last change with git in a couple of keystrokes.

However, having an our $VERSION in every module would be good practice. I would have a script to update them all automatically. This is what I do in my modules.

PhilterPaper commented 3 years ago

Just to be clear, I do have our $VERSION in all .pm and most .pl files, and the build process updates it to the current release.

It occurs to me that $LAST_UPDATE might be useful if you're looking at the GitHub, where $VERSION isn't yet set. I don't see that setting $VERSION on GitHub would be particularly useful -- does anyone feel it would be? I would have to update every file at every release.

PhilterPaper commented 3 years ago

What I think I'll do is change my $LAST_UPDATE to our $LAST_UPDATE on-the-fly during the build for the next release, and see if anyone complains (and if the original requestor is happy with it). This way it's easy enough to back it out on the following release if necessary.

PhilterPaper commented 3 years ago

Implemented in 3.023 (probably to be released by the end of the month). We'll see if anyone complains.