[tz] Are tzdata2016g & tzdata-latest missing the VERSION file?

Barry Allard barry.allard at gmail.com
Fri Sep 30 22:34:47 UTC 2016


One common release engineering pattern is to have a release script which
builds, runs tests, bumps the version by removing -dev from the version in
a commit, tags it, build/hashes/signs/releases artifacts and then really
bumps the {{next minor ver}}-dev version in a new commit on master and
finally pushes commits and tag. Then, it ends up that master will usually
contain a -dev version (and is always stable) and releases are non-dev.
Bonus points for gpg signing commits and tags, and using signed-of-by.

On Fri, Sep 30, 2016 at 11:53 AM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 09/30/2016 11:04 AM, Alexander Belopolsky wrote:
> >
> > There would be little harm in keeping the version in the repository's
> > Makefile as well.
>
> I'm afraid I see some harm. Yes, bumping the release could be done
> automatically or semiautomatically as part of a release procedure, along
> the lines that Paul Koning suggested. But this would mean that the only
> time the repository Makefile's version number would be correct would be
> near the time of a release; at most other points of time the version
> number would be wrong, and this would be confusing. Also, it would mean
> that bumping the release would not be an atomic operation, as it is now.
>
> I'm also worried that downstream distributors will modify the data but
> still call it "2016g". We are considering installing the version number
> along with the other data; if we do that, this mislabeling problem will
> get worse because the wrong label will become part of the runtime
> environment, and having the wrong version number in a development
> Makefile will likely contribute to the mislabeling.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160930/038b2b92/attachment-0001.html>


More information about the tz mailing list