Triplea: Prepare for 1.9.0.0 release branch

[ssoloff]

4162 is a high-priority regression in the current stable release (1.9.0.0.12226). As has been previously discussed, in order to push hotfixes for the current stable, we'll need to fork a long-lived release branch from 1.9.0.0.12226 from which new GitHub releases can be made.

The purpose of this issue is to ensure everyone's on the same page with what has to be done to achieve this. My proposal is below. Please feel free to recommend changes or add steps I may not have thought of.

Create release branch

The first thing to do is fork a new branch from tag 1.9.0.0.12226. The new branch will live in this repo and won't be deleted until the next major release is complete. Future 1.9.0.0 hotfixes will be pushed to this branch. I'd propose a Gitflow-style name for this branch like release/1.9.0.0. Other suggestions are welcome.

The Travis build configuration will then have to be modified to produce release artifacts from that branch, in addition to master. That is, a new GitHub release (and tag) will be created whenever merging to master or release/1.9.0.0.

Bump version on master

Because releases will be produced from two branches, we should bump the version on master to avoid confusion when talking about releases (e.g. 1.9.0.0.12520 is based on current stable, but 1.9.0.0.12521 is based on incompatible master).

I don't know if the new incompatible release should be 2.0 or 1.10. Since we're creating an incompatible release, I'd vote to change version semantics and go full semver (especially in light of our repeated attempts to remove the fourth semantic version component a la #4195). Therefore, my vote would be to bump the version to 2.0.

Syncing hotfixes between release branch and master

My suggestion would be to implement all hotfixes directly against the new release branch. Thus, PRs are created against that branch and merged there.

Once the fix is confirmed on the release branch, a second PR will be created to apply the hotfix to master. I suspect, in most cases, a cherry-pick will work. However, if the release branch and master have diverged sufficiently, the original PR author will have to effectively re-implement the fix in the second PR.

[RoiEXLab]

@ssoloff

Because releases will be produced from two branches, we should bump the version on master to avoid confusion when talking about releases (e.g. 1.9.0.0.12520 is based on current stable, but 1.9.0.0.12521 is based on incompatible master).

👍 Agreed

I don't know if the new incompatible release should be 2.0 or 1.10. Since we're creating an incompatible release, I'd vote to change version semantics and go full semver (especially in light of our repeated attempts to remove the fourth semantic version component a la #4195). Therefore, my vote would be to bump the version to 2.0.

I'd actually prefer 1.10, bumping the major version number implies more changes than just a little bit of savegame incompatibility IMO, but I'd be okay with both. 👍 for semver though.

My suggestion would be to implement all hotfixes directly against the new release branch. Thus, PRs are created against that branch and merged there.

Once the fix is confirmed on the release branch, a second PR will be created to apply the hotfix to master. I suspect, in most cases, a cherry-pick will work. However, if the release branch and master have diverged sufficiently, the original PR author will have to effectively re-implement the fix in the second PR.

👍

[ron-murhammer]

@ssoloff Pretty much agree with everything. I'd probably lean towards a 1.10 as well though.

[DanVanAtta]

branching

The first thing to do is fork a new branch from tag 1.9.0.0.12226

Agree, will the branch need to be a long-lived branched? What if we made the needed commits, pushed to some branch and pushed a tag? That was intended to trigger the release process as well, with some luck that still works. If so, we would repeat the process from the new tag, eg: 1.9.0.0.12226.0, 1.9.0.0.12226.1, etc..; thoughts? would that work?

version on master

Perhaps a miss to not update this when we broke compatibility. Let's get this incremented to 1.10. 2.0 when we drop numbers.

build config updates

The Travis build configuration will then have to be modified to produce release artifacts from that branch, in addition to master. That is, a new GitHub release (and tag) will be created whenever merging to master or release/1.9.0.0.

We can do this by hand. Perhaps let's do the: build artifacts, push tag, upload by hand 2 or 3 times first before we automate it? I wonder when we hit diminishing returns of doing this by-hand vs automating. Do we think we'll certainly need to do this hot-fix process a number more times?

I want to be sure we keep things simple and consider options. To that extent, a hybrid approach of keeping a release branch and pushing tags from it perhaps could be a useful concept. It seems the choice is between: { tags, branchs, both}, and there is an open question if any tag push will still trigger a github release.

[simon33-2]

Should we make it 1.10.0.build?

I think the last blocker to that has been removed but if we encounter any others we should remove them when we find them.

Even better IMO would be 1.10.build but that requires a few more changes so perhaps go to 1.10.0.build for now with a view to changing it to 1.10.build before we go live with 1.10? Would that satisfy everyone?

Regarding the branch being long lived, I think it would have to remain alive until the bots stop running with it. I wouldn't be a fan of having the branch not being present while it needs to be being used.

[RoiEXLab]

I think we probably want to have 1.10.build, however this will probably cause confusion because the build number always counts up, regardless of the convention to set the patch version number back to 0 after incrementing major or minor.
There's a semver extension that supports the concept of a build number, so we could have the patch number reserved for increments when releasing a new stable if someone comes up with a good idea on how to do that in travis.

[simon33-2]

But for the present we need to deal with 1.10.0.build don't we? Or don't you accept that argument?

[ssoloff]

What if we made the needed commits, pushed to some branch and pushed a tag? That was intended to trigger the release process as well, with some luck that still works.

Pushing a tag does not trigger a release:

https://github.com/triplea-game/triplea/blob/c7b112f183f6286f857df1455af48ba2b04bb283/.travis.yml#L49

will the branch need to be a long-lived branched?

I see a few problems with _not_ having a long-lived branch:

1. As more hotfixes are pushed, it becomes harder to visualize history.
2. Custom changes have to be made to _.travis,yml_ to enable releases from a non-master branch. If you forked from a tag for every hotfix, you'd have to reapply those changes each time.

We can do this by hand. Perhaps let's do the: build artifacts, push tag, upload by hand 2 or 3 times first before we automate it? I wonder when we hit diminishing returns of doing this by-hand vs automating.

The Travis build only produces artifacts if it also uploads them to GitHub releases. Even if we modified the build to produce artifacts without creating a release, there's no way (AFAIK) to manually download artifacts from a Travis build (i.e. you always need to push the artifacts out of the build in order to preserve them).

So, without Travis, a dev would have to build the artifacts locally for upload to GitHub releases. Publishing stable artifacts from a dev-local build is unacceptable, IMO.

Do we think we'll certainly need to do this hot-fix process a number more times?

My guess is it's going to take us several more months to put out 1.10. I'm willing to bet that someone is going to report a must-fix bug in 1.9 during that time. :smile:

[ssoloff]

however this will probably cause confusion because the build number always counts up, regardless of the convention to set the patch version number back to 0 after incrementing major or minor.

That is unfortunate on its face, but go back to the discussion we had a few weeks ago about version _qualifier_ vs. _buildId_ vs. etc. We should be thinking of that last version component as simply an opaque identifier that helps us uniquely identify the build that produced the artifact. It doesn't necessarily have to be a monotonically-increasing integer.

[simon33-2]

I don't really think it's a problem if you have releases with numbers like this:
1.9.0.0.12226
1.10.12500
1.9.0.0.12600
1.10.12800

[ssoloff]

I'm pretty sure everything's in place now to generate new 1.9.0.0 releases. With #4245, a new GitHub release will be produced when merging PRs to the release/1.9.0.0 branch (e.g. 1.9.0.0.12616).

[DanVanAtta]

Sorry, not much time to weigh in, but why not flip this flag and save a LOT of work?

 tags: false 

I'm inclined to say we do these releases fully manually even.

[ssoloff]

Sorry, not much time to weigh in, but why not flip this flag and save a LOT of work?

I don't think it's that simple. IIRC, simply flipping that switch leads to an infinite build loop as both normal master builds and tag builds then produce GitHub releases, which create new tags, which produce new releases, which create new tags, ad infinitum.

I wrote a fairly detailed analysis of the problem last year. Even with a solution that gets rid of the infinite build loop, there were inconsistencies between the build number embedded in the artifact and the actual number of the build that produced the artifact (see the examples provided in the analysis).

save a LOT of work

Well, as of today, the release branch already exists. So to submit a hotfix, one would simply follow the normal PR process except for targeting the release/1.9.0.0 branch instead of master. Other than that, nothing else needs to be done. It should Just Work (e.g. #4252).

I'm inclined to say we do these releases fully manually even.

As I mentioned above, I think having a dev produce an official release on their local machine is not an acceptable solution.

[simon33-2]

triplea-game.org/download still has build 12226.

Shouldn't we be including #4252, #4336 and hopefully #4348?

[ron-murhammer]

@simon33-2 Yeah, the first 2 are already merged into the 1.9 branch and can be tested here: https://github.com/triplea-game/triplea/releases/tag/1.9.0.0.12959. I'd like to push the last one into the 1.9 branch as well, get a few people to test it, and then update the stable download.

[simon33-2]

Ok, can we get that merged in? Is it just a merge involved?

[ron-murhammer]

@simon33-2 Need to cherry pick the #4348 commit and create a PR against the 1.9 branch. If you want to take a swing at it feel free. Otherwise I can try to do it tonight or later this week.

[ssoloff]

@ron-murhammer I edited your previous comment to indicate it's #4348 that needs to be cherry-picked (you had #4338).

[simon33-2]

Might have a go at that tonight.

[ssoloff]

Re-closing this issue, as it was intended to discuss how to _prepare_ for a 1.9.0.0 release branch. As the release branch is now in-place and has been used for two hotfixes thus far, I don't think there's anything that would necessitate keeping this issue open any longer.

[simon33-2]

Ok but I still have a problem in that the hot fixes have not been deployed to triplea-game.org yet. Isn't that just a matter of updating a pointer?

[ssoloff]

@simon33-2: Yes, @ron-murhammer simply needs to mark a new tag as the latest release, and it will then be available on the triplea-game.org downloads page. However, the plan, as I understand it, was to test 1.9.0.0.12959 through this past weekend, and if no issues arose, to promote it to stable. But now that we're considering including #4348, my guess is that has temporarily been delayed. The sooner #4348 can be merged into the release/1.9.0.0 branch, the sooner it can be tested, and a new stable can be released.

[simon33-2]

PR #4351 created.

Had to reapply the change - couldn't wrangle GIT to incorporate Ron's commit unfortunately. Rebase runs into problems with that annoying file which had carriage returns in it. Perhaps it would be possible on Windows?

[ron-murhammer]

@simon33-2 Merged. We should get new 1.9 artifacts built here shortly. Once we do a bit of testing on that version we can look to update the website download.

[simon33-2]

So in the future, if we have a bug for which we know we want a patch do we have to do it twice or if we do a "git reset" to the head of the release/1.9.0.0 branch we'll be able to do the change once?

[simon33-2]

There will be a fourth regression.

AxisandAllies.org just migrated to NodeBB forums.

[ron-murhammer]

@simon33-2 Yeah, I'd like to get the PBF A&A posting updated before we push out a new download now.

[simon33-2]

Hmm, any idea of what is needed?