Triplea: Release 2.0

[ron-murhammer]

Let's use this thread to discuss the release but the project board for tracking tasks: https://github.com/triplea-game/triplea/projects/14

Below is OUTDATED

So I'd like to try to put a stake in the ground on what we want to finish up before releasing 1.10. Its been quite a while since we pushed out a release and have a lot of changes.

• [x] Tackle the "pre-release problems": https://github.com/triplea-game/triplea/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22Pre-Release+Problem%22
• [x] Versioning
• [x] User password plan
• [x] Certs for the HTTP server (https)
• [x] Upgrade to Install4j8
• [x] Remove moderator API key password

Is there anything else in progress that we want to finish?

---

Release Plan:

• [x] Finish final changes and fix release blockers
• [x] Update release notes
• [x] QA testing of candidate pre-release version
• [x] Fire up new lobby DB and migrate data
• [x] New lobby in place with https server and bots
• [x] Assign super mods
• [x] (+2 weeks) Mark candidate pre-release version as release
• [ ] (+3 days Update triplea min version
• [ ] (+1 weeks) Remove most bots from old lobby
• [ ] (+1 weeks) remove all bots from old lobby
• [ ] (+1 weeks) turn off old lobby

[RoiEXLab]

I think @DanVanAtta wanted some incompatible changes to get through before pushing a new release, but I'm not entirely sure if that's up-to-date information.

But nothing to add from my side

[DanVanAtta]

It seemed like we agreed the next version would be 2.0 and we'd begin with the updated version semantics. Updating that is perhaps the last non-compatible change we should put in.

My 2 cents, we should also begin on 3.0 very shortly after we fix the release blockers. The efficiency gain of not testing backward compatibility and the freedom to change things was very valuable.

The release itself we should plan relatively well. We need to consider:

• how exactly the login piece will go. Mass emailing users with a temp password to log in to the new lobby is an option. In that case the migrated code can have the old password column dropped
• How well we can increment the 'min TripleA version' flag. Recall there is a bug in 3xxx series that crashes game clients.

So far AFAIK we are committed to spinning up a parallel lobby and DB and asking users to switch over. Essentially we'd re-label the latest prerelease lobby as the 2.0 lobby and call it production while users switch over. I suspect we'll want a 'soft-release' period of a week or two before we start to ask users to upgrade with a hard cut-over after perhaps around 4 weeks.

[RoiEXLab]

@DanVanAtta Another thing to consider regarding password policy:
We could write code that checks if users have a migrated password. In case they don't, they are required to reset their password using the default reset password prompt.
This has the key benefit that this approach would work even when the user wouldn't recieve an email (might be an invalid address or the user might not notice because spam filter or other things) indefinitely.
The only drawback is that this would require a small amount of overhead code that only handles those kinds of legacy cases. But having seen you password reset pr I believe this overhead to be minimal, but it should definitely be documented.

[DanVanAtta]

That's a good option, might be better to do just that rather than sending mass emails out. Any thoughts if we should do both, send emails with temp password or just prompt users to reset password if they do not have a bcrypt password set? I suppose in either case we can simply drop the old password column.

[prastle]

Most of our players use the new forum. 4 weeks of an old lobby should be enough
Ignore the mass email it never really worked last time. Just my two cents

[prastle]

Just change the header in the lobby with the time limit of closure etc.

[DanVanAtta]

@prastle When have we sent a mass email before? To be sure, we're not advertising a new lobby, we'd be sending a temporary password as those who are still on v3xxx will no longer be able to log in to lobby when we go to v2.0.

[DanVanAtta]

We need to check v3xxx as well to verify that we do see a game freeze when the TripleA min version is updated. IIRC that will be the case due to a bug in that version; in that case we'll need to be careful about when we do the hard cut-over.

[ron-murhammer]

@DanVanAtta 2.0 is fine with me. I wasn't sure where the versioning discussion ended up. And yes we need to plan exactly what needs done especially since this is the first incompatible release with the new infra automation. Usually we host the old lobby for a few weeks to allow people to finish up their games.

I'd prefer no mass emails as I don't think it'll be effective and many existing users probably have garbage emails. We need to either carry the old passwords forward or provide a mechanism for people to reset their passwords when trying to login.

[DanVanAtta]

reset their passwords when trying to login

The forgot password feature provides this : )

In essence we'd add some logic to detect if a user only has a legacy password, if so we'll show a prompt asking them to use the forgot password button to get a temp password and then reset it

[Cernelius]

Looking forward to finally being able to use the prerelease in lobby.

Really strange that nobody knows what the numbers in like 1.8.0.9 were meant to signify, especially the first one, and also strange now we will see 2.0, 3.0 etc. after so many years of so many 1.x despite some huge changes at time, but you are the developers here now.

[prastle]

@danvanatta just to refresh your memory @roiex and I sent the last mass emails when the old warclub and lobby closed

[DanVanAtta]

@ron-murhammer updated the overview with a draft release plan; I'm also remembering we should get the new http server on https.

[DanVanAtta]

I created a release 2.0 project to give us some swimlanes for the tasks that we need to do and those we completed: https://github.com/triplea-game/triplea/projects/14

[DanVanAtta]

Migrated this to a project: https://github.com/triplea-game/triplea/projects/14

[simon33-2]

If we've finally bitten the bullet and gone to version 2, perhaps we could drop the ".0" from the versioning and go full semantic?

[RoiEXLab]

In case you didn't notice, we have a 3 number versioning scheme now.

[DanVanAtta]

Re-opening to coordinate project discussion.

https://github.com/triplea-game/triplea/pull/5786 (websocket ban wiring) is perhaps one of the last http server parity tasks replacing the previous lobby server.

Arguably we probably want a nicer unit-scroller before releasing, I think that's justifiable and is not a ton of effort. @RoiEXLab or @asvitkine , please volunteer if you have capacity.

Otherwise we should focus on bug-fixing, QA, identifying gaps, and generally considering the pending 2.0 feature-set closed. It's really important we get all issues worked out so we don't have to deal with roll-back issues (let's nail this release!).

cc:/ @asvitkine @RoiEXLab @ron-murhammer @panther2 @prastle

I'll try to get prod servers cut/deployed this weekend. With luck we'll get to a soft launch in a couple weeks. Please check the release 2.0 project board and feel free to add any tasks there: https://github.com/triplea-game/triplea/projects/14, the release is complicated enough that the project is essentially tracking multiple checklists

[ron-murhammer]

@DanVanAtta @RoiEXLab Thoughts on where we are at here? I see a few remaining open issues:
https://github.com/triplea-game/triplea/issues/5856
https://github.com/triplea-game/triplea/issues/5792
https://github.com/triplea-game/triplea/issues/5216

Are these the only known outstanding issues? Can we release even with those or do they need resolved?

[RoiEXLab]

I believe #5856 can be closed no Idea about the other 2 issues.

[DanVanAtta]

I fear there has been a communication breakdown and it's my fault to not have resolved that sooner.

1. We should be, and should have been doing full regression testing for some time now. We need to try and see if there are any more problems in any area of the game.

2. I think the perception of prerelease is incorrect. It is not early access. Instead it is for test and demo. The features in prerelease should not be considered stable. I mention this as I know there are a lot of downloads/usages of prerelease, but the number of bug reports do not seem to match. My impression is that the high usage of prerelease is driven by the desire for early access rather than testing. To this point, early access is less important if we can actually ship the release. I think this is notable as lack of both testing and fixes are the things currently slowing down the 2.0 release.

[DanVanAtta]

We're getting lower on the pre-release bug tickets! We need to double down on QA efforts, see if we can find any more problems. Perhaps even triple, eh, our efforts?

It's been a lingering task of how to more or less automatically create moderators in prerelease and not have those accounts be deleted if we recreate database. I think for now that is an okay liability and it's not expected to happen.

@prastle, @Cernelius , @panther2 , @ron-murhammer , @RoiEXLab ; would you all mind creating accounts on the prerelease server? I'll bump @prastle and @ron-murhammer to admin. @prastle please then upgrade the other accounts to 'moderator' through the new toolbox, let me know how that goes, and then everyone else please see what you think about the toolbox and focus some testing there.

The lobby was re-written 100% in this upcoming release, it perhaps should be a strong focus of QA verification.

[panther2]

I am travelling (without Java-enabled PC) until next week (not yet sure when back home) and will be happy to assist, then.

[RoiEXLab]

@DanVanAtta Already had an account there.
One thing we should perhaps do before releasing: Going back to prerelease.triplea-game.org instead of the prerelease2 subdomain, we no longer need that one 😅

[Cernelius]

@prastle, @Cernelius , @panther2 , @ron-murhammer , @RoiEXLab ; would you all mind creating accounts on the prerelease server?

Done, as "Cernel".

[prastle]

I used to have one but I will check. @Cernelius

[DanVanAtta]

I would be very surprised if you have a prerelease account. If so, forgot
password is something you can use. The DB of prerelease is not at all the
same as prod and there is a chance we would reset its data at some point.

On Fri, Mar 6, 2020, 4:32 PM prastle [e-mail] wrote:

I used to have one but I will check. @Cernelius
https://github.com/Cernelius

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/triplea-game/triplea/issues/5025?email_source=notifications&email_token=AC6SZOKBVX3W72ZLY2OZO2TRGGIYJA5CNFSM4IN6SVH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODIXOA#issuecomment-596020152,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC6SZOME52RTX57F2BFONQLRGGIYJANCNFSM4IN6SVHQ
.

[prastle]

I am connected with a new account (no longer a mod) and can't host @DanVanAtta
error message is "Failed to connect to : wss://prerelease2.triplea-game.org/remote/actions/ws

[prastle]

@DanVanAtta

[DanVanAtta]

@prastle I used the toolbox to promote your account to admin. Please note the distinction between admin and mod, admins are mods but they can promote other users to mod or admin. Using the toolbox, please see if you're able to use the toolbox to make Cernel a mod and Roi an admin. Let me know if you run into any issues.

[beelee1]

@DanVanAtta
nice work on the issues. Down 20 or so. I won't bug here anymore. Just wanted to acknowledge it :)

[prastle]

@DanVanAtta I am now logged in as a mod and it allowed me to add them both and promote RoiEX. It should probably show a name saying (SMod) or something but no biggee. Also it allows hosting again good job! BUT it still shows the silly error message.

[ron-murhammer]

@prastle Or maybe (Admin) for the couple of users that can then promote mods and other admins.

[prastle]

Yes that works as well @ron-murhammer also if you create an account I can upgrade ya. Interesting to note we cannot directly add to database....

[RoiEXLab]

BUT it still shows the silly error message.

Are you sure? The error popup went away for me after the fix

[prastle]

@RoiEXLab here is the screen shot

[RoiEXLab]

@prastle Ah thanks for the clarification, that's a different endpoint @DanVanAtta and I forgot.

Looks like we have to add more endpoints @DanVanAtta 😅
We really need a good long term solution for this.

[panther2]

@DanVanAtta

@prastle, @Cernelius , @panther2 , @ron-murhammer , @RoiEXLab ; would you all mind creating accounts on the prerelease server?

Registered as "Panther" today.

[prastle]

Added @panther2 as "Panther" as a mod.

[Cernelius]

I would assume the current 2.0 should be upgraded to 2.1 when released (thus the release being the first 2.1 version). Am I correct?

[DanVanAtta]

Probably 2.0 as there has yet to be a 2.0 release yet.

[Cernelius]

Shouldn't have been, then, upgraded to 2.0 only in the moment of releasing that specific release?

Anyways, I feel like strongly suggesting upgrading the first or the second digit each single time a new released is made, for the released version. This is important in the moment mapmakers set the minimum version in the xml, also possibly referencing it in the notes of the game.

Since it is already 2.0, then I suggest having it as 2.1 starting from the released version (the next stable).

[DanVanAtta]

The number leading version number (ie: "1" -> "2") is incremented as soon as compatibility is broken. Second digit is the "major" release number, we are still on release number '0' and will increment it to '1' after '2.0' has been released and we have a new (compatible) major release available.

This is important in the moment mapmakers set the minimum version in the xml, also possibly referencing it in the notes of the game.

Referencing engine version in map notes I do not think is very advisable. Under what contexts do you see that as necessary @Cernelius ? My opinion and advocacy on the the issue is that map compatibility version should be completely independent of version numbering, at some point there will be more and more technical difficulties supporting that. It's a different topic, but I advocate we create "map XML" versions, similar to how HTML has a doctype and a version, that is different from the HTTP protocol version that transmits HTML documents.

Since it is already 2.0, then I suggest having it as 2.1 starting from the released version (the next stable).

The concept of 'stable' and "unstable" is outdated. Ideally all built versions are "stable" and the code is never made "unstable". The "unstable" model comes from SVN and email days when a release was declared with a contribution deadline. All code contributors would then email their patches to the one master project maintainer who would have then apply them all to the code base. With all changes made at once, without being tested together or even individually sometimes, the result was a code base that was almost always unstable. The new model seeks to avoid this in a number of ways. Once we get back to compatible changes only, in theory any new update would almost become immediately a new release. Having a schedule for 'major' release is something for us to consider, but I'm already digressing from the main topic of this thread quite a bit now..

TL:DR; it's still would be 2.0 as we are still on a 1.9.x as the released major version.

[Cernelius]

If the criteria for upgrading the first digit is broken compatibility while the criteria for upgrading the second digit is that version being a new release, then, unless the two happens exactly for the same version, a new incompatible release should always be X.1. This is the only way it really makes sense to me, but, of course, this is a matter you have decide between you developers.

Mapmaking wise, a current example is something that worked one way in a 2.0 and another way in another subsequent 2.0, and I need or want or reference the latter, then I would set the minimumversion at 2.1, as long as that is the same as the latest 2.0.

[Cernelius]

I'm pretty sure that about whoever, in the moment you say "this game requires minimum version TripleA 2.0", is going to assume the game works fine with the 2.0.x or 2.0+x having the smallest "x", that would be the main referenced version, as being the first of the 2.0. I really think this is the normal, or at least most understandable, way of referencing versioning. Then, the third ever-increasing digit could remain as only a prerelease, if not unstable, thing, that you shouldn't need to reference in your maps (also, in the moment it is not set at 0 each time a new versioning happen, it is not really part of the versioning, but just another parallel versioning).

[DanVanAtta]

@Cernelius it's possible we could have 3 different successive releases be created in a single day. A "major" release is a semantic thing where there are enough new items we want to put a new number to it.

Mapmaking wise, a current example is something that worked one way in a 2.0 and another way in another subsequent 2.0

That would contradict compatibility. That 'something' was itself perhaps unstable and only considered 'beta'. 2.0.x has been out for so long this has become a notable problem. In theory none of the 2.0 map features should have been put into any map with an expectation of permanence until we made an official 2.0 major release.

I'm pretty sure that about whoever, in the moment you say "this game requires minimum version TripleA 2.0", is going to assume the game works fine with the 2.0.x or 2.0+x having the smallest "x", that would be the main referenced version, as being the first of the 2.0.

It's a bit odd as we are in a mode where any 2.0.x right now can be incompatible with previous 2.0.x, by agreement. In essence, all 2.0.x versions are development versions. One way to think about it, as soon as we have a major released version of 2.0.y, all versions 2.0.x, such that x < y should be considered development versions and effectively deleted.

[DanVanAtta]

Then, the third ever-increasing digit could remain as only a prerelease

The third digit never resets to zero, it is the build number; it is meaningless in the context of 'major' release or 'prerelease'

[DanVanAtta]

Not all of the pre-release problems need to be fixed in order to release 2.0:

• https://github.com/triplea-game/triplea/issues?q=is%3Aissue+is%3Aopen+label%3A%22Pre-Release+Problem%22

We may want to track 2.0 "must-do" items in a project swim-lane or create a tag for it, for now. I think on the list of pre-release problems we only must-fix the PBEM password field missing and the ghost players. The battle calc crash is of concern, that might be a must-fix.

Otherwise it seems we need to simply rally around testing, if we get the couple problems above fixed then we should be able to do a soft-release.

[Cernelius]

Not all of the pre-release problems need to be fixed in order to release 2.0

Getting back the "Release Blocker" label, on the account that not all prerelease only problems are necessarily blokers?

Also, I think that the "Pre-Release Problem" label should be renamed as "Pre-Release Only", to be clearer and avoiding the redundancy with the "Problem" label, it goes with anyway.

Actually, this issue:
https://github.com/triplea-game/triplea/issues/5921
has the "Pre-Release Problem" label but not the "Problem" label.

[DanVanAtta]

The redundancy in labels is notable. Might be nice to avoid the label management. There is a 'projects' tool which is maybe better geared for this kind of tracking: https://github.com/triplea-game/triplea/projects/14

Regardless, the big gap is testing everything and being sure that we know the full set of items that need to be fixed.

[ron-murhammer]

@DanVanAtta @RoiEXLab So I think the plan is to try and address as many "Need to do" items on the project board as possible this week then start a full round of testing next weekend: https://github.com/triplea-game/triplea/projects/14

I'll post on the forum to recruit and let the testers know.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If there is something that can be done to resolve this issue, please add a comment indicating what that would be and this issue will be re-opened. If there are multiple items that can be completed independently, we encourage you to use the "reference in new issue" option next to any outstanding comment so that we may divide and conquer.

[Cernelius]

How much stale is this release? I'm interested to know how many weeks since now 2.0 is expected to be released, even if just guessing.

it's possible we could have 3 different successive releases be created in a single day.

I definitely suggest each release changing at least one of the first two digits. So, for example, if 2.0 would be release thrice the same day, then I believe the second and the third one should be, respectively, 2.1 and 2.2. It would be definitely not helpful if you would have more than one release with the same two first digits (since the third one is not actually a third digit).

[DanVanAtta]

@Cernelius I hope sooner rather than later. The 'must-do' column is the one to watch in the 2.0 release project: https://github.com/triplea-game/triplea/projects/14

For release number, the fist digit is compatibility and has a technical meaning. The second is the 'release' notification. Until we decide to go for a non-compat, we may see the latest get updated somewhat frequently to pick up the latest code. When there is an accumulation of enough updates that we think it's worth for everyone to update, then the 'release' number (the second) number is incremented. Basically that means enough features have accumulated to call it a new release. Hence 1.9 and 2.0 really have been 'release families' with high levels of compatibility.

Hence, we wouldn't want to increment the second digit on any old code update that is perhaps invisible to the user but we have updated the latest available for download. Ideally testing is done over much smaller updates and more frequently, it avoids this situation where we spend 5 months looking for bugs (we've been in a bug find and fix mode since January).

With that said, a non-compat release is perhaps special, we could arguably consider a 2.0 a development release and the 2.1.x to be the first official latest; that would not be unreasonable.

[Cernelius]

I'm really not seeing the difference here between a 2nd digit only increase and a new release with the same first 2 digits. In both cases, as I understand it, nobody needs to update anything, and the only difference is that, in the first case, you would suggest people to upgrade, while, in the second case, you would not. The very concept of "advertising" a new release is not much a reason for versioning, as you may as well stop advertising anything at all for every release, letting people go clicking and see if what is offered is the same of what they have or not.

If such a distinction is advisable, then I would have a 3rd digit for all new but "unadvertised" releases (the ones that now would have no digit change at all, beside the development number).

I mean, a release can be still silent and unadvertised while upgrading the 2nd digit. My point is that I believe all releases should be distinguishable, from one another, without having ever to refer to the development version (the pseudo-third digit). I also really don't like the fact that the development version is a digit at all (it was not, in 1.8.0.9 and beforehand, as far as I know).

Of course, just the opinions of a non-developer.

[DanVanAtta]

@Cernelius I think the disconnect is that the development version is a release version. It is exactly an "unadvertised" release. By default, every new version pushed to github releases is a release version, we had to configure it manually to toggle them as prerelease. It is intended actually that every code update would produce a new release version. That vision remains a goal though, the code is still far too brittle and has too little automated test for us to always be sure everything is good after each change. Though, the days where Veqryn collects all changes via email, puts them together and then produces an 'unstable' version are gone. When so many changes are glued together there is no telling what will be working, particularly with that level of change.

So in essence, after accumulating a large number of changes, where there are new features, and we really would like everyone to get on the same version, that is when an 'advertised' release comes along.

Regardless, we are getting off track in discussing versioning - this topic has been discussed to death in at least 4 other issues..

[DanVanAtta]

2.0 project is updated: https://github.com/triplea-game/triplea/projects/14
Status is looking pretty good:

• 2.0 servers are deployed
• All major bugs & known problems are fixed

Just need to migrate 1.9 DB data to 2.0 (likely will be just the users table) & reconnect bots. Not much otherwise before we can do a soft-release and a general release after that.

[prastle]

I would like to repeat that I believe we need a clean database

[prastle]

Thus release as is and anyone joins registers

[DanVanAtta]

@prastle that would reset everyone's join date and require additional communication for people to re-register. We will need compelling reasons to drop all user data and reset from zero.

[DanVanAtta]

I just finished migrating 1.9 user data to 2.0

The scripts used are documented in: https://gist.github.com/DanVanAtta/46a828294be308658aff013047aa1cff

I've assigned @ron-murhammer , @RoiEXLab , @prastle and myself as admins. @prastle, I'll leave it to you to assign additional moderators. Let's please be sure to have a discussion between us if we think we need more admins.

[Cernelius]

I realize it shouldn't be a non-developer saying so, but isn't it advisable not to merge any PR but fixes until releasing?

[DanVanAtta]

That's an old model where change rate, is risky, untested and often
breaking, hence unstable. In new model change is frequent, small, high
confidence and the code is always stable.

There are large impacts to buffering changes that cause overhead and higher
risk since you cant test with what will be the latest. Because changes are
buffered, they're larger, less tested because they are not integrated with
latest, which makes them risky and the cycle of less change and more
breakages continues.

On Wed, Jun 17, 2020, 4:45 AM Cernelius [e-mail] wrote:

I realize it shouldn't be a non-developer saying so, but isn't it
advisable not to merge any PR but fixes until releasing?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/triplea-game/triplea/issues/5025#issuecomment-645324612,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC6SZOIPMFHDKUJPORQV6G3RXCUF7ANCNFSM4IN6SVHQ
.

[DanVanAtta]

@Cernelius as a better answer, you described the 'unstable' / 'stable' release model. We have a different release model and do not do code freezes.

[DanVanAtta]

There's nothing left on the project must-do column and we've been in soft-release for some time. https://github.com/triplea-game/triplea/projects/14

I'm thinking we'll make the latest as a release shortly, perhaps tomorrow night or Monday.

[panther2]

@DanVanAtta
Before the release I can only kindly ask that someone looks into #6717 .

PBF is most popular on A&A .org and this issue is really disturbing and would cause much trouble.

[DanVanAtta]

Looks like @RoiEXLab has.

We should keep in mind that the only 2.0 'blocking' items are going to be either:

• relatively major problems that make 2.0 unplayable
• moderate problems that require an incompatible fix

To keep in mind we can/will release compatible updates on a somewhat frequent cadence. It is not the case that we need to fix everything or hold our peace.

[prastle]

I sent you a PM @DanVanAtta it might be inconsequential but it appears the prod 2 bots are not relaunching. They work fine in .200081. Will they need to be micro managed through infrastructure every update?

[RoiEXLab]

Also given that @FrostionAAA confirmed that the StackOverflowError does no longer occur for him we might be in a good shape to go for a "hard" release.
I wonder if this also solves this issue: #6723

[prastle]

Other than that I fully agree to release and test after fixing pbf

[DanVanAtta]

I'll emphasize, while some problems are not great, we can and will be releasing updates potentially every 1-4 weeks until we decide to break compatibility. It's going to take some time to convince players to migrate; if we can fix a problem that impacts a minority of games with a compatible fix, it's not something to hold up the release over.

Second, we need to be sure we mark any 2.0 activities in the project tracker, us all keeping our mental lists of things that needs to be fixed is not tenable, the project is there for a reason. If the project says there are no more 'must-fix' items, then there are no more must-fix items.

[DanVanAtta]

2.0.20123 has been marked as latest.
Knocking out items listed on the 2.0 release project.

[Cernelius]

In the 2.0 release, or anywhere else, I'm not finding any information about when the old 1.9 lobby will be shut down. People having old save-games may be interested in knowing that (and asking moderators about it). Example:

(03:15:23) GeneralEmCgee: any ETA for how much longer 1.9 will stay up?
(03:15:29) Cernel: no idea
(03:15:50) Cernel: I will ask

Also I'm not sure why the 2.0 release project it is still open in the moment it is only missing "Update partner sites with new download link" and I guess that won't be done, as it would not make sense to update them for 2.0 when 2.1 is already released.

Also, does it make sense to have the 2.0 release issue closed but the 2.0 release project open?