Next Compatible Release #1768
Comments
ron-murhammer
added
the
Discussion
|
Doesn't it have to be 1.9.0.x? Changing that breaks the old jar interface further so shouldn't be done IMO. |
|
@ron-murhammer Are we changing the versioning system before releasing a new stable release? BTW. Removing unused branches on the repo is probably a good idea: |
ron-murhammer
changed the title
|
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 |
|
@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. |
|
@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 |
|
@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: |
|
re: bugged The latest release is all way back in january (https://github.com/triplea-game/triplea/releases/tag/1.9.0.0.3635). |
|
I thought the bug was resolved based on the issue being closed and the PR merged? |
|
I see, in one sense there were two issues:
Hence the gap and different views.. 😿 Happy to draw lessons - but, we do need to move forward.. |
|
I suggest as a plan (100% open to discussion):
|
ron-murhammer
changed the title
|
@DanVanAtta Yeah, that works. I was primarily using this issue to track point 3. |
|
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? |
|
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. |
|
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. "<?xml version=1.0 ?>" works but "<?xml version=1.0?>" 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 |
|
@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.xmlRepo says the same thing: 0 bytes. |
|
Doh! Looks like the bulk update stuffed up. I'll fix it. |
|
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. |
|
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? |
Bug fixes and testing. All the features we were trying to get in are there. |
|
@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. |
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.
That's a good suggestion |
|
I agree with the suggestion to restore the default look and feel to Graphite. Looks much nicer to me. |
|
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. #1768 |
|
It is caused by this, modifying the game_engine.properties files and adding an extra digit should temporarily workaround this issue. |
|
Well my concern is that it is stable on the website now. It needs to be fixed fast. @ssoloff @ron-murhammer |
|
I changed the release back to pre-release state until we adressed this issue. |
|
ty |
|
#2470 has a fix |
|
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:
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. |
|
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? |
|
QA group could not break: https://github.com/triplea-game/triplea/releases/tag/1.9.0.0.7062; it has been marked as latest 🎊 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
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 |
|
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. |
|
Interesting point about the latest_version check. I guess that is a fair argument for the status quo. |
|
I created triplea-game/triplea-game.github.io#253 as a starting point for the 7062 release notes. |
|
Shouldn't the latest stable include #2483? The path forward IMO should be:
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. |
|
@simon33-2 During the weekend a new stable release etc is a bad idea (jmho). |
|
build 7062 hasn't been deployed to the bots has it? |
|
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 |
|
What we really need is a server loaded |
|
7062 is missing a fix though. |
|
Then load a new server with the bots ya want to test :) |
|
I already did put up a server a while back. Seems a bit pointless to redo unless there's agreement about the path forward. |
|
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! |
|
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. |
|
@simon33-2 We should try to run through basic testing and look to update the download soon. |
|
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? |
|
@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. |
|
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 |
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:
The text was updated successfully, but these errors were encountered: