Triplea: Next Compatible Release

[ron-murhammer]

So we have a few threads floating around on the next release and incompatibilities (#1735, #1715, etc). So I wanted to get a more concise list of issues we want to complete before releasing with the idea of the following release we could then break compatibility.

Remaining Features For Release:

• [x] Allied fighters on retreating carrier bug #1404
• [x] Derby Migration #1758
• [x] Incompatibility Fixes #1745
• [x] Handle redirects when getting download length #1718
• [x] Re-review and test PR #1646
• [x] Restore L&F to Substance Graphite #2391
• [x] Regression testing with no outstanding issues

[simon33-2]

Doesn't it have to be 1.9.0.x? Changing that breaks the old jar interface further so shouldn't be done IMO.

[RoiEXLab]

@ron-murhammer Are we changing the versioning system before releasing a new stable release?
If we do, we should probably update the code to be able to "recognize" any newer versions before releasing a new compatible stable.
Other than that I don't have anything to add...

BTW. Removing unused branches on the repo is probably a good idea:

[DanVanAtta]

Hmm, I'm afraid I may be starting to be a bit confused.

One note, the next release we mark as stable, must be 1.9.0.0. Recall that the current version most people are on is bugged if we do a version upgrade. With that said, I am interested in marking the latest release as stable ASAP, so we can get back into the habit of doing that after every few changes.

Following through from that, once we're ready for the non-backwards compat release, I thought we would then jump to a our new 3 number release numbering system (notably so we don't keep bringing up and redoing release numbering so many times)

@ron-murhammer / others: kindly confirm if that is the plan

[ron-murhammer]

@DanVanAtta Not following you on why its bugged? The idea is to just increment the last non-build number so we can drive most folks to upgrade as we haven't pushed the changes out for a while otherwise they never upgrade.

[DanVanAtta]

@ron-murhammer is the plan to set the next number to 1.9.0.1 when we are ready for non-backwards compat, and then work on the 2.0.build migration, and then release directly as 2.0.build? (which means 1.9.0.1 would never be officially released)

[ron-murhammer]

@DanVanAtta No. My thought was to release 1.9.0.1 as the last backwards compatible release before we start working on non-backwards compatible changes and revising the versioning.

So releases would go like this:
1.9.0.0 - current
1.9.0.1 - next compatible (soon)
2.0 - not compatible with new versioning

[DanVanAtta]

re: bugged

The latest release is all way back in january (https://github.com/triplea-game/triplea/releases/tag/1.9.0.0.3635).
Recall when we tried to bump version, we had game clients lock up: https://github.com/triplea-game/triplea/issues/1493
The fix for that was pushed in: https://github.com/triplea-game/triplea/pull/1558, which unless I have my dates crossed, is not part of the current stable.

[ron-murhammer]

I thought the bug was resolved based on the issue being closed and the PR merged?

[DanVanAtta]

I see, in one sense there were two issues:

• game is locked up, nobody could join the lobby, this was a fire (#1493)
• we would have problems on upgrade (was not explicitly tracked)

Hence the gap and different views.. :crying_cat_face: Happy to draw lessons - but, we do need to move forward..

[DanVanAtta]

I suggest as a plan (100% open to discussion):

• regression test the latest master, mark it as stable
• figure out how to determine how many people would be impacted by a version upgrade. Start coming up with a plan to minimize that somehow. Meanwhile we'll get back into our 'normal' release mode and push out additional compatible releases as we can
• finalize list of things to get out before a last compatible release, and get them all out
• bump version number, merge some non-compatible stuff - start full-blown work on non-compatible release stuff
• time goes by, 6~12 weeks
• finalize on the user impact mitigation
• release next non-compatible version

[ron-murhammer]

@DanVanAtta Yeah, that works. I was primarily using this issue to track point 3.

[simon33-2]

We can update the version number so long as we don't change the latest_version file.

Not following why we would do something different?

[simon33-2]

BTW, We've already had a master called 1.9.0.1 so I think it should go to 1.9.0.2, or 1.9.0.build.

[simon33-2]

Getting set of console errors with the latest build, 4684.

It seems that the issue is related to the first line of the xml on a lot of maps. "\" works but "\" doesn't. The difference being the space before the second question mark. Should this be solved with a bulk update or an engine change? I would say it needs to be fixed before marking the current release stable.

triplea.engine.version.bin:1.9
Could not parse:file:/home/simon/mapsrc/domination_1914_blood_and_steel/map/games/Domination_1914_Blood_And_Steel.xml error at line:1 column:1org.xml.sax.SAXParseException; systemId: jar:file:/home/simon/TripleA_1.9.0.0.4684/bin/triplea.jar!/games/strategy/engine/xml/; lineNumber: 1; columnNumber: 1; Premature end of file.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:150)
at games.strategy.engine.data.GameParser.getDocument(GameParser.java:272)
at games.strategy.engine.data.GameParser.parse(GameParser.java:81)
at games.strategy.engine.framework.ui.NewGameChooserEntry.(NewGameChooserEntry.java:56)
at games.strategy.engine.framework.ui.NewGameChooserModel.createEntry(NewGameChooserModel.java:195)
at games.strategy.engine.framework.ui.NewGameChooserModel.addNewGameChooserEntry(NewGameChooserModel.java:167)
at games.strategy.engine.framework.ui.NewGameChooserModel.populateFromDirectory(NewGameChooserModel.java:213)
at games.strategy.engine.framework.ui.NewGameChooserModel.parseMapFiles(NewGameChooserModel.java:76)
at games.strategy.engine.framework.ui.NewGameChooserModel.(NewGameChooserModel.java:43)
at games.strategy.engine.framework.ui.NewGameChooser.getNewGameChooserModel(NewGameChooser.java:198)
at games.strategy.engine.framework.startup.mc.GameSelectorModel.selectByName(GameSelectorModel.java:326)
at games.strategy.engine.framework.startup.mc.GameSelectorModel.loadDefaultGame(GameSelectorModel.java:312)
at games.strategy.engine.framework.startup.mc.GameSelectorModel.lambda$loadDefaultGame$100(GameSelectorModel.java:265)
at java.lang.Thread.run(Thread.java:748)

[ssoloff]

@simon33-2 It looks like the latest game XML for that map is empty:

ssoloff@localhost ~/triplea/downloadedMaps/domination_1914_blood_and_steel-master/map/games 
$ ll
total 0
-rw-rw-r--. 1 ssoloff ssoloff 0 Jun  9 05:22 Domination_1914_Blood_And_Steel.xml

Repo says the same thing: 0 bytes.

[simon33-2]

Doh! Looks like the bulk update stuffed up. I'll fix it.

[simon33-2]

One minor issue - the right panel on "Start Local Game" sometimes doesn't refresh properly when leaving a game and loading it. I think it's to do with the %income change. Not sure exactly how to reproduce it.

[simon33-2]

I believe #2080 resolves point #5 of the OP.

[simon33-2]

Fair dinkum guys. There's been a number of improvements since build 3635 more than six months ago but we are still waiting for them to be included in the generally available release. What exactly are we waiting for? Derby Migration? If this is the problem, can I suggest we drop that change from the feature list?

[DanVanAtta]

What exactly are we waiting for?

Bug fixes and testing. All the features we were trying to get in are there.

[ron-murhammer]

@DanVanAtta @ssoloff @RoiEXLab I believe with merging #2209 that addresses all known regressions outside of the lobby admin database issues which already exist now #2204. IMO, we should be able to release soon unless other bugs are reported. Thoughts on timeline?

Also, for now should we restore setting the L&F to Substance Graphite? Otherwise I have a feeling we will get lots of negative feedback.

[DanVanAtta]

Thoughts on timeline?

We're now testing 6157: https://docs.google.com/spreadsheets/d/1CSZ4s7wBLcvgue_IHwl-CbjQd95qj8hhR8m89ngCzbU/edit?usp=sharing

IMO a few days for that, this weekend to late next week I would expect for us to mark something as a release. Then a few days after that I would recommend to update the lobby message.

Also, for now should we restore setting the L&F to Substance Graphite? Otherwise I have a feeling we will get lots of negative feedback.

That's a good suggestion

[simon33-2]

I'm disappointed that the review of #1646 has been ticked off without merging #2080. It's a nice usability improvement for my money.

BTW, what's the version number going to be? 1.9.0.build (which I would endorse)?

[simon33-2]

I agree with the suggestion to restore the default look and feel to Graphite. Looks much nicer to me.

[ron-murhammer]

@DanVanAtta @RoiEXLab @ssoloff I think we should be pretty much ready to release the next stable. Only thing left I think is to restore Graphite L&F default.

[ssoloff]

@ron-murhammer I'm hoping to submit a PR within the next 24 hours related to #2169. The only reason I would want to get it in before the next release is because it changes where the master password used for encrypting credentials is stored. That's a feature that will first appear in the next release, so changing it now won't break compatibility (except for our beta testers who use the latest pre-releases :smile:).

It's not a terribly big deal if it doesn't get in before the next release. We can either live with the break in compatibility (which simply means users must re-enter their saved PBEM/PBF credentials), or I just add extra code to migrate the master password from its old location to the new location.

[ron-murhammer]

@ssoloff That's fine, we can wait for that. Just want to get it out in the next few days as its been dragging on especially while we seem pretty stable.

[RoiEXLab]

Not that important, but just for the sake of consistency: I'd like to merge #2358 before releasing a new stable.
The changes are just backwards compatible server-side, but we probably want to have the exact same version as stable and as lobby.

[simon33-2]

Hallelujah!

Happy to wait for those two issues.

What about #1739? Shouldn't we get rid of the fourth version number?

[simon33-2]

Logged PR #2394 for removing the 4th version number.

Note that latest_version should not be changed!

[simon33-2]

Can I suggest that the removal of the old jar mechanism should be held over until the next incompatible release? I find that mechanism really useful.

[DanVanAtta]

my 2 cents, as soon as we have testing cleared, we should release: https://docs.google.com/spreadsheets/d/1CSZ4s7wBLcvgue_IHwl-CbjQd95qj8hhR8m89ngCzbU/edit?usp=sharing

I would also recommend everyone taking a stab at testing and add a column in that sheet and also test the latest version. It's pretty surprising how many usability issues and other bugs can be found.

We have been trying to work out the bugs for some time. Recall too the current version has an upgrade bug so we cannot change major versions until most people have upgraded. It will be difficult to do that as we will have to just ask people to upgrade.

[RoiEXLab]

@ron-murhammer @DanVanAtta @ssoloff
I edited the old 1.9.0.1 milestone and used it as "tracking label" for issues that _definetely need_ to be adressed before releasing a new stable.
There are just 2 things I'd like to personally get done before a new stable: #2358 and one thing I noticed: The automatic update checking does not make use our "new stable workflow" e.g. using the GH API to determine the latest stable release.
I'd like to replace the latest_version.properties File with a couple of requests to the Github API.
This files does contain more than just the latest version, it includes a link to the changelog + the download link. While we probably can hardcode the download link here as well, we should be able to move the changelog link to another place or have a unified scheme for the links. (e.g. something like triplea-game.org/release_notes/#1.9.0.0.). Alternatively we should include the link in the github-release-description

[prastle]

(Gives a silent noob cheer in background ) :)

[DanVanAtta]

The automatic update checking does not make use our "new stable workflow" e.g. using the GH API to determine the latest stable release.

I'm not 100% sure we should do that. If we do, we can't have a 'soft-release'. Also, I really do expect us to start marking releases as stable on a weekly or bi-weekly basis. That would be too fast a cadence for the normal user to be upgrading. (Noting, 95% of all release versions will be backward compatible, I would expect non-backward compatible to be once or twice a year, and with current efforts to improve compatibility problems, then maybe almost never!)

[RoiEXLab]

@DanVanAtta If you worry about the message being displayed too often, we could of course implement a cooldown which makes TripleA not check for updates for the first month after a update

[prastle]

Somewhat off topic ( but quite about this ) is the simple point that in the old days everyone had one engine. A stable engine. We need everyone on the same one again. Jmho. It is very difficult to test glitches when George has 37, Sue has 38 and I have 41. Just my two cents worth. Either way you guys are getting there and an amazing job with all the new changes :)

[DanVanAtta]

I'm more worried about releases going out to every player and then us realizing pretty quickly there is a bad bug, and then downgrading the latest release. In that case everyone then has to downgrade, and we potentially have a number of games that are in limbo as well. The alternative I imagine is we mark the latest as stable, then ideally some small percentage would use that version and we would get more feedback before releasing to the entire community.

Month cool downs I think is also pretty arbitrary. I'm not sure we even need to notify players of the latest release if things are backwards compatible. When discussing the 3 point version system we reserved one number simply as a way for us to notify players of versions we would like them to upgrade to. Most updates should be really minor. Hence the month cool down would even be more arbitrary, not clear if it fits. The trade off is just really keeping the existing mechanism, I suspect we may be simply getting a bit too fancy by automating that (not entirely clear how much burden we are removing from what is just a simple file update)

[DanVanAtta]

We need everyone on the same one again.

We may never quite see that again, the pace of development is MUCH faster in github. Also I'm not sure I agree on that need. If versions are backward compatible, and if there are minor differences between versions, I don't quite see the problem if people are on different build numbers.

[ron-murhammer]

Yeah, my thought is the update prompt should only push users to a new major/minor not build version (if we go with 3 point version system). That way for the daily/weekly releases that are just updating the last version number, new downloaders and testers could grab them but not push everyone forward as we will probably end up having more bugs in these. Then when we look to do a major/minor version increment we do a bit more testing and look to drive people forward to that version.

[DanVanAtta]

I agree, but one comment on:

forward as we will probably end up having more bugs in these

WE really need to avoid that! If we are lax and allow 'unstable' versions then we'll be back in the mode of endless bug fixes and testing before releases. I really want to emphasize we need a process that is going to catch most of these issues. We have the testing group as a last line to make sure we don't repeat some of the previous horrible mistakes, but again, that is a last line and should not find any new bugs.

[ron-murhammer]

@DanVanAtta Agree but we also have to be realistic given the amount of automated unit tests and number of developers/testers we have. We do need to be better around keeping things stable and trying to push releases out more often. I think some of the major changes like the database migration, map download/XML changes, and user preference refactoring (while great changes) need to maybe be considered a little more carefully to avoid ending up with as many issues as we did.

Open to ideas around how we avoid unstable versions and keep things on a more regular schedule. It mostly comes down to individual developers making a better effort to test/verify their changes (preferably in an automated fashion) otherwise we shift back to putting too much burden on PR reviewers.

[ron-murhammer]

@ssoloff @RoiEXLab @DanVanAtta I think we resolved all issues needed to put out the next release. Would you agree? Can we update the download to the latest (1.9.0.7029) today?

[ssoloff]

Agreed. Copying @panther2 and @prastle just in case the test team has observed any blocking issues in the recent builds.

[ssoloff]

@ron-murhammer Actually, won't there have to be at least one more build? Does the version need to be bumped to 1.9.1? Or did @simon33-2's recent change effectively take care of that by moving the build number into the micro position? (Sorry, I'm still confused a bit by the current versioning rules.)

Regardless, I'm assuming that latest_version.properties still has to be updated after we've promoted a release.

[RoiEXLab]

@ssoloff The latest_version.properties file is just used to check for newer versions of TripleA (I still think the GH api should be used for that task, just like the website does.
For the website to offer the new version the pre-release-checkbox just needs to be unchecked which makes deployment of a new stable very easy.

We should also update the lobby in the next week or so to fix a couple of db issues

[simon33-2]

Does build 3627 contain the fix to the latest_version.properties check? Hopefully you remember what I'm talking about.

If not, we need to leave latest_version.properties at 1.9.0.0. I think we should probably leave it there for a while regardless.

[simon33-2]

Regarding bumping to 1.9.1, no. We can't nor shouldn't do that. That would make it an incompatible release.

[ssoloff]

@simon33-2

Does build 3627 contain the fix to the latest_version.properties check? Hopefully you remember what I'm talking about.

Are you referring to #1558? If so, then no that's not in 3635. Good point, though. If we update latest_version.properties, then pretty much every current user is going to experience a hang. So maybe we should avoid updating latest_version.properties for this release?

[simon33-2]

Oh, in fact, #1558 isn't in build 3635. There is no way we can bump latest_version.properties without causing all existing installations (besides pre-releases) to hang.

[simon33-2]

Oh, you answered the question before I did. What's with the question mark at the end of your post though!?

[ron-murhammer]

Yeah, the thought is to just mark the latest (1.9.0.7029) as stable (not pre-release) so the website download points to that. It appears there is agreement on that and unless any objections are made in the next few hours then I plan to do it tonight.

[prastle]

Um The new release cant use any bots. We will need the bots updated before it becomes stable.

"Client is using 1.9.0.7029 but server requires version 1.9, games.strategy.net CouldNotLoginException"

[prastle]

@panther2 can you try to join a bot and confirm this?

[panther2]

Indeed, @prastle

[RoiEXLab]

Should be an easy fix, but probably requires updating the bots as well as the client...

[panther2]

Yes, @prastle and me tested that some minutes ago and @prastle found out that this might be due to the removed digit from the version number.
Using 1.9.0.0.6991 works fine.

[prastle]

True but then all old games dont work. Also no one using old can join new and vice versa we just tested.

I believe @simon33-2 said this here as well. https://github.com/triplea-game/triplea/issues/1768

[RoiEXLab]

It is caused by this, modifying the game_engine.properties files and adding an extra digit should temporarily workaround this issue.

[prastle]

Well my concern is that it is stable on the website now. It needs to be fixed fast. @ssoloff @ron-murhammer

[RoiEXLab]

I changed the release back to pre-release state until we adressed this issue.
While we could fix this issue by simply updating all the bots to the new stable version, we will run into the exact same issue again once we have a new build, so holding for now, I might be able to open a PR later this day which fixes this issue

[prastle]

ty

[RoiEXLab]

https://github.com/triplea-game/triplea/pull/2470 has a fix

[DanVanAtta]

Please use the testing group to answer "when can I release": https://docs.google.com/spreadsheets/d/1CSZ4s7wBLcvgue_IHwl-CbjQd95qj8hhR8m89ngCzbU/edit#gid=800027447

If you see 2 or 3 sign-offs next to a version number then it is okay to mark that version as the latest github release. Testers will pick up versions as fast as they can. We use the test sheet to be able to converge on specific versions and give the multiple Okays.

---

Latest version bug: yes, this is present in the current version which everyone has. That should not be updated for at least a few weeks/months from now so we don't crash clients en-masse. Here is the updated plan:

• wait for okay on testing
• mark that version as latest in github releases
• begin 'soft release' time period. Do not advertise the new release yet during this time. We only want a few number of users to be using the very latest and give us a chance as well to find anything else. This is to simply reduce risk and the reduce the 'blast radius' if there are any problems. The soft release window should be at least 7 days.
• Once soft release is closed, update lobby messaging that latest version has bug fixes
• After a week, take the lobby messaging down
• When we are ready to release the next incompatible, then we will open a forum thread to note anyone still on the old version will crash when we update the latest_versions file. We can give a cut-off date for that in the forum thread and message that in the lobby as well. I think we may be working on this next incompatible for anywhere from 3 to 9 months. That will give everyone a good bit of time to jump off of the latest version: 3635.

---

Bots + Lobby deployments, if they are compatible with 3635, they can happen at any time assuming reasonably low impact. Bots are easier, since more frequently idled, but lobby should be updated for code reasons only if there is a good reason. DB updates should be transparent, but please run by/through me first. Once we have our DB code in source control, then you'll no longer need me to run prod DB updates.

[simon33-2]

Should we retire the check on latest_version if we can easily just check the github API before marking this as stable? Or is that not easy to achieve?

[DanVanAtta]

QA group could not break: https://github.com/triplea-game/triplea/releases/tag/1.9.0.0.7062; it has been marked as latest :confetti_ball:

Please do not "advertise" we are on a new latest until 10/19. After then we'll update lobby message and create a forum post notifying people that a new latest has been released. In the meantime we need to get to work on the release notes: https://github.com/triplea-game/triplea-game.github.io/blob/master/release_notes.md

---

Re: Should we retire the check on latest_version

It's an interesting idea using github API. If we had enough testing to replace everything the testing group does, then I would say yes to this. A trade off is that if the messaging is fully automated, buggy releases become more costly to downgrade since way more people would have already upgraded.

Which I do think raises another topic/issue, can we replace the lobby_properties check with something less brittle?

[simon33-2]

Shouldn't #2483 be merged first? Otherwise the version needs to remain at 1.9.0.0 for a long time. That's why I put on the cranky pants that a conflicting change was proposed and merged.

[simon33-2]

Interesting point about the latest_version check. I guess that is a fair argument for the status quo.

[ssoloff]

I created triplea-game/triplea-game.github.io#253 as a starting point for the 7062 release notes.

[simon33-2]

Shouldn't the latest stable include #2483?

The path forward IMO should be:

• upgrade stable to include all changes on master
• mark as stable
• merge no other changes to master
• convert version number to 1.9.0.build on master
• upgrade bots to stable
• mark new master as stable
• restart merging

Then at least Triple-A will know what version it is and you'll be able to see it in Help|About.

I suppose an alternative would be to create a branch based on build 7062 and merge #2483 onto it. Seems like too much work though.

[prastle]

@simon33-2 During the weekend a new stable release etc is a bad idea (jmho).
(75 players in the lobby atm all bots full and I added some myself.)
We can shut down a bot server and test during the week with a test lobby or separate bots? Atm I have had np with 7062. Up to you guys about future.

[simon33-2]

build 7062 hasn't been deployed to the bots has it?

[prastle]

Correct but I would like to announce happily that 2 have been running for three hours (my own bots) So i tentatively think we are good to go. With 7062

[prastle]

What we really need is a server loaded
with new stable bots
jmho
@simon33-2

[simon33-2]

7062 is missing a fix though.

[prastle]

Then load a new server with the bots ya want to test :)
Cash is there 5 bucks for a test server
:)
For a month
Or just reload a server during the week
since we dont need 20 bots during the week.

[simon33-2]

I already did put up a server a while back.

Seems a bit pointless to redo unless there's agreement about the path forward.

[prastle]

The problem is not the bots. The problem is without a forced update we will never find all the glitches between an old map and a new; an old version and a new engine version. Thus having one bot server running new is probably a good idea (Renamed new stable bot engine). Just My thoughts. You guys are the devs I am just a lobby guy. Great work at all btw!

[simon33-2]

Shouldn't we bump along this now? If we aren't happy with build 7062 then why is the version which is available to be downloaded.

[ron-murhammer]

@simon33-2 We should try to run through basic testing and look to update the download soon.

[simon33-2]

Ok, so it looks like build 7378 is the new stable. Will that be deployed to the bots?

What's the plan to go forward, stick with only compatible changes or is there a plan for an incompatible release?

[ron-murhammer]

@simon33-2 Once we determine 7378 is the new stable that we want everyone to move then then we'll announce it on the lobby and look to upgrade the bots. After that I would like to consider doing a incompatible release so we have a bit more freedom to make some changes.

[RoiEXLab]

Closing this issue, as the current version seems to be pretty stable, although perhaps we should push the release one release further because of the bot issue we encountered and is fixed in 1.9.0.0.7534