Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include build time in version string, rather than placeholder #832

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

eddyashton
Copy link

@eddyashton eddyashton commented Sep 25, 2023

The string Version 2.18 of Day Month 20?? appears in all TLC outputs. Although it is followed by a git revision, it's not immediately clear how old the related build is.

This PR replaces that placeholder Day Month 20?? with the actual build date, ISO ordered for international clarity matching previous format, so we now get a more friendly line:

TLC2 Version 2.18 (nightly) of 25 September 2023 (rev: 28c8edf)

I note that versionOfTLC is used in many places, not just printWelcome(). I assume they'll also appreciate the change, though I don't know how to confirm that.

@lemmy lemmy added the enhancement Lets change things for the better label Sep 25, 2023
@lemmy
Copy link
Member

lemmy commented Sep 25, 2023

In a release, the date will be formatted as TLC2 Version 2.18 of 20 March 2023, and the absence of a timestamp used to mark tla2tools.jar as a nightly build. How about formatting the date as seconds since epoch in nightly builds => easily distinguishable yet solves the problem?

By the way, TLCGet("revision").date equals TLC's build date.

@eddyashton
Copy link
Author

In a release, the date will be formatted as TLC2 Version 2.18 of 20 March 2023, and the absence of a timestamp used to mark tla2tools.jar as a nightly build. How about formatting the date as seconds since epoch in nightly builds => easily distinguishable yet solves the problem?

By the way, TLCGet("revision").date equals TLC's build date.

How is that done - is the string manually edited for a real release?

I think adding "2.18 (nightly)" or "2.18 (candidate)" would make this distinction clearer, but I'm also happy to match the existing date format if there's precedent in prior releases (ie - potentially other tools parsing this).

Standard date format, while retaining nightly distinction

Signed-off-by: Eddy Ashton <edashton@microsoft.com>
@lemmy
Copy link
Member

lemmy commented Sep 25, 2023

Exactly, the string is manually edited. :-)

@lemmy
Copy link
Member

lemmy commented Sep 27, 2023

It occurred to me that TLC2 Version 2.18 of Day Month 20?? is also hardcoded in the Toolbox. :-( There are also version strings and dates for SANY, PlusCal, ...

@ahelwer
Copy link
Contributor

ahelwer commented Mar 19, 2024

I don't think this is a good idea for build reproducibility reasons. Timestamps are the classic example of something you should never include in the build if you want it to be reproducible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Lets change things for the better
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants