Prereleases numbering has been reset?

[asvitkine]

Prereleases numbering has been reset?

Seems new prereleases have low numbers like:
https://github.com/triplea-game/triplea/releases/tag/2.6.6

There's two problems with this:

1. They don't actually show up as the latest in the list, presumably due to sort order? https://github.com/triplea-game/triplea/releases/tag/2.6.996
2. They will soon collide, since we already have old prereleases like 2.6.100: https://github.com/triplea-game/triplea/releases/tag/2.6.100

[DanVanAtta]

Looking at the list of releases, it looks like they sort chronologically and not by name:
https://github.com/triplea-game/triplea/releases

Do you see different @asvitkine ?

2. They will soon collide, since we already have old prereleases like 2.6.100:

There is a little bit of breathing room there, not a lot though. This should be fixed before then.

---

The root cause is the name of the github action file was changed that pushes the release. That resets the 'run number' back to 1.

[asvitkine]

No, I see 2.6.7 now too, at the top. But what happened to 2.6.6, 2.6.5, etc?

[asvitkine]

I think it's sorted by the title, and 2.6.7 was the first one on Jun 27th.

[DanVanAtta]

We'll be in for trouble come July.
It's possible to head directly to those expected releases, they are there, and are pretty recent.

It's hard to tell what the sorting is. This SO suggests it's taggerDate: https://stackoverflow.com/questions/44862992/what-is-the-order-in-which-github-lists-tags-releases

[DanVanAtta]

#10796 will update the version numbers to replace run number with Git SHA. That would avoid the impending numbering collision.

[asvitkine]

I really like the run number (when it works correctly - i.e. consecutively), since it lets me tell if one version is later than another (very helpful when bisecting, or just updating prereleases on my different computers and knowing how far behind I am).

Could we keep it and do some hack where we add some extra string prefix to avoid the collision.

Alternatively, could we do something like 2.6.20220627-1, 2.6.20220627-2, etc - i.e. use the date and the run number within the same date?

[DanVanAtta]

I like this, but the date in version number creates a problem which is non-trivial to solve:

2.7.0827+SHA
2.6.0703+SHA
2.6.0627+SHA

[major].[release].[MMDD]+[Git SHA]

The above gives the date in a more compact way and makes the versions sort more nicely compared to just [major].[release]+SHA

Sort Order Reference

For sort: https://github.community/t/release-page-not-sorting-correctly/121002

Tags are sorted by the timestamp of the underlying commit that they point to
If those commits are created on the same day, then the sorting is based on Semantic Versioning of the name of the tag (https://semver.org/ 48)
If the Semantic Versioning is the same, they are sorted by second of creation

Challenges

Challenges (1) and (4) are a factor for anything that includes dates or times. We can possibly solve that though by having the deploy system look for latest artifacts (file system timestamp) and then parsing the version number from those files.. Though, if we do that, then the version number could be wrong for when we create folders on the server.

Challenges (2) & (3) speak to the benefit of not having run number

(1) - Need build number in two places at different times - need to keep them in sync

One thing that has changed is that we are always building master/HEAD and then releasing. Previously we hardcoded the version value so when we did deployment, we knew the version value. That has now become dynamic which creates a challenge.

There are two places & times when we need version number during the release & deploy process. First when we start a release, when we start building artifacts (Jars & Game Intallers). Next, we need to know the version value when we start a deployment, so we know the names of the file we will copy to remote (lobby & bot) servers.

One interesting implication for any timestamp values in the version number: if enough time passes between build and deploy, then deploy might expect a different timestamp from what was generated at build time (any timestamp value more granular than hours would always fail as it takes more than a minute between release & deploy)

Possible solution We could have the deploy system find the latest built artifact (or fail), and parse the version number from the artifact name.

(2) What version number to use when building & deploying on-demand?

There could be another github action to run a release & deploy on-demand. This would have its own run number. While we might not release from this job, if did only deploy with this job - it would look odd on a server that a lower run number is actually more recent.

(3) Build System Deplendency/Lock-In

It would be frowned upon, but we could build locally and deploy those artifacts. If we can't do that, it implies we are locked into the build system somehow. Being locked into a build system is not a great thing, removes flexibility and implies some pain when/if we have to move the CI/CD.

(4) Gradle might not know to clean build - wrong artifact name expected by deployment

If gradle has already built, it will not rebuild artifacts. When deployment kicks in, it'll evaluate what it thinks should be the build number for artifacts. This could create a mismatch between expected version numbers.

Let's say we generate a UUID and pass that to both gradle and the deploy system. If we build twice, gradle will only build artifacts once (because nothing has changed). On the second build, we'll pass the same UUID to both gradle and the deploy system, and the deploy system will not know about the dirty build and would fail to find artifacts.

Possible solution this could be solved with same solution of deployment looking for latest.

[asvitkine]

By the way, the new hashes thing is resulting in incorrect ordering on the prereleases page.

https://github.com/triplea-game/triplea/releases

2022-June-30 - 2.6+886ea23 is above 2022-June-30 - 2.6+3e0397e, despite the later being released later.

[asvitkine]

One other simple solution to consider:

We could just change the current version to 2.6.1 and keep the numbering scheme sequential as before, so the numbers become 2.6.1.N and don't collide with anything and we still get the benefit of sequential numbers and good sorting on the release page.

(We could also just bump to 2.7 with a 2.6 release, but it seems a bit silly to do that just because we accidentally reset the numbers.)

[TheDog-GH]

Im not a fan of the new Prelease numbering system.

Please can we go back to sequential numbering.

In TripleA the engine version displayed is 2.6+d3acaac this will cause problems when trying to find the version on Github that caused the problem in the first place.

[asvitkine]

One more downside of the current naming scheme - the + gets URL-encoded for the actual github prerelease download page.

So we have to replace it with %2B when going to a URL like: https://github.com/triplea-game/triplea/releases/tag/2.6%2B3479832

This makes sharing a specific prerelease link a bit more cumbersome with players you're playing with. (Of course, this could be mitigated by having in-game UI have a link to the corresponding release page, but this problem didn't exist before we switched to hashes.)

[DanVanAtta]

Bumping version number to solve ordering

@asvitkine simply bumping version unfortunately does not solve the new problem we have "(1) - Need build number in two places at different times - need to keep them in sync" and "(2) What version number to use when building & deploying on-demand?"

#10788 (comment)

Finding specific versions

@TheDog-GH said: " 2.6+d3acaac this will cause problems when trying to find the version on Github that caused the problem in the first place."

Could you help clarify how finding "2.6+d3acaac" is much different from finding say "2.6.20"?
I know the ordering is incorrect, but assuming we can fix that - is there really an issue?
In both cases you can hack the URL and find the release directly: "https://github.com/triplea-game/triplea/releases/tag/2.6+d3acaac"

Considering the release pages can get quite extensive, going directly to the URL is arguably easier in all cases compared to finding an older pre-release like 2.5.x

URL Encoding

Why does the URL encoding make the link any more complicated to share? The non-encoded version of the link works as well (eg: https://github.com/triplea-game/triplea/releases/tag/2.6+d3acaac). If both the non-encoded and encoded version work, can you help clarify @asvitkine how that makes the release link harder to share?

Further, what is the use-case for sharing the release link? If it is to give a link for the latest pre-release to download, pretty soon the latest pre-release will always be the release. In this case you can just say "download from the website" via the main download method: https://triplea-game.org/download/

[DanVanAtta]

@asvitkine let me try to state the new constraints more precisely:

• we need a stable version number that is deterministic. This allows to build assets with a given version number and then again later find those same assets for deployment. Previously the build number could be whatever, and we then hardcoded the version to deploy. Now, those two values must be lined up and are generated at build & deploy time.
• We may deploy on-demand, this means 'run-number' cannot be in the version, the 'run-number' would be different on a different job. This could cause oddity on the server where we have a version '2.6.1+' that is ahead of '2.6.5+', or we could have colliding run numbers on the server that again make it odd. This might not be a problem for too long as we will overwrite any previous '2.6' versions and it is only the 'major.minor' that would be used. Still, we have the hidden pitfall if the job changes at all then the run number resets.

[DanVanAtta]

@asvitkine re- ordering. Same day results right now might be out of order. Github releases is very opinionated to assume releases will be a semver. Only if the semver matches does it then fallback to release date. See "sort order reference" posted ealier: #10788 (comment), https://github.community/t/release-page-not-sorting-correctly/121002

Perhaps if we re-push the same tag with only a major.minor in the tag, we should fix the sort order. The order is seemingly based on the tag name, rather than the release name. Not having a tag for each release is maybe not a bad thing. Github releases might be wonky if we delete tags that have releases attached them, it is something to check.

[TheDog-GH]

@DanVanAtta
Could you help clarify how finding "2.6+d3acaac" is much different from finding say "2.6.20"?

You have asked me to find the version that has caused the problem, this is a lot easier when its 2.6.20 because as you described it, you keep halving the numbers (20, 10, 15, 13 etc) till you get to the problem. You cant halve "d3acaac".

As an alternative file format how about 2.6-YYYY-MM-DD-HH-MM-SS or similar?

[DanVanAtta]

@TheDog-GH The example of bisecting by version number is an interesting consideration. When bisecting myself, I use a list of git commit SHA's and then bisect that list. As a side note, I wonder if it would be easier to show you how to checkout & build a specific version the next time as that is faster than installing. Because I use git SHAs to do so, I had not considered that use-case.

The change in format is not whimsical but is due to new constraints. To try and explain more concisely, going from a hardcoded release number to "release what you just built" is the difference.

To explain the build flow, after we merge PRs they are built via github actions which first executes a build (which creates a lobby zip file that we copy to the lobby server), and then we copy that build artifact to the server. In order to copy the artifact, we need to know its name. The process for when we build & deploy happen about 5 minutes apart. So if we use a time stamp that changes more often than that, then every build would fail as we would try to copy artifacts with the wrong name.

To recap what we need to solve this problem:

• a monotonic increasing sequence
• a stable value that does not change during the build process
• (very nice to have) not tied to any specific build system (eg: travis, github actions)

(A) I was thinking a database sequence nearly fits this bill, but adds a good bit of complexity and particularly complicates ad-hoc deployments that are done from local laptop rather than on github actions. (B) Another thought I had was to use the last tag value and to increment that, though that could get confusing.

I think commit-number could do the trick. Basically count how many commits there are on 'master' and that would be our build number.

[TheDog-GH]

Naively, this used to happen, I think automatically?

Bump feign-core from 11.8 to 11.9 (#10792)
Bumps feign-core from 11.8 to 11.9.

Couldn't the same style of naming be used for pre-releases?

[asvitkine]

I think commit-number could do the trick. Basically count how many commits there are on 'master' and that would be our build number.

I like that idea. If we have access to commits, we could also look at the date of the last commit and the number of commits that date to also do the 20220701.7 format, if we wanted.

But commit number has the advantage of making bisect easier as mentioned above, since dates don't correlate consistently with with number of commits.

[DanVanAtta]

Unfortunately the CI does a sparse checkout and reads the number of commits as '1'.
I'm working on removing version number from build artifacts. Recall, that so long as we use version numbers in the build artifact file names, then the build will always fail at specific times of day. By removing that version number from the file names, we are freed up to possibly using formatted dates as our increasing sequence number.

[simon33-2]

en the build will always fail at specific times of day

So this is the reason the system was changed? Ok, but when the build is done, the version number is not included in the file. UNIX build is now called TripleA_unspecified_unix.sh

Not good. I think the major and minor numbers should always be included, and also something to distinguish each build. Similarly for the default install directory.

[DanVanAtta]

So this is the reason the system was changed?

@simon33-2 , no, that is just a problem/constraint that we need to address due to releasing the latest version on each deployment. The deployment config previously "knew" what to deploy based on a hardcoded value. If we are deploying the very latest, then we have a new problem of knowing exactly which version was the latest that we just built (so we can deploy/upload that)

The change in format is not whimsical but is due to new constraints. To try and explain more concisely, going from a hardcoded release number to "release what you just built" is the difference.

Ok, but when the build is done, the version number is not included in the file. UNIX build is now called TripleA_unspecified_unix.sh

Yeah, that's just a recent problem, not part of any kind of final design. See #10882

edit said in more short, when you are deploying latest, you can't deploy a hardcoded version (you need to deploy the latest, hence the need for a release version that is consistent so it can be referenced in differing parts of the deployment)

[DanVanAtta]

@asvitkine commit number as build number is working now. Just needed to update the checkout fetch size to get all of the history. Releases from the same day are sorting well again.