Release Schedule

[frank-weinberg]

[significantly edited 2023-04-21]

Based on a suggestion by Danger Muffin on the WFTDA forums, I want to introduce a predictable release schedule:

(At the moment any aspect of this is can be changed if someone brings up a good reason to change it.)

• New Major versions will be released once per WFTDA competitive season. If rules and/or procedures are also released on a per-season schedule we will align with that release. Otherwise we'll release after WFTDA world championships with beta/prerelease versions available in the months before the release.
• These releases will be numbered based on the year that contains most of the regular season they correspond to, i.e. v2023.x, v2025.x, ...
• Within a major version no changes will be introduced that could cause officials or announcers to adjust their workflow on game day, even if that adjustment is optional. Other changes will only be introduced if their effect on the look and feel of the software and their risk of introducing bugs is small.
  • Exceptions to this can be made for changes that address major pain points like what we are discussing in #603
• Minor versions will still be released as they are ready.
• I'm aiming to release v2023.0 at the end of May with a prerelease version that includes at least #603 in the first half of the month. I will go over the open tickets and flag ones that I'll try to include in 2023.0 in the next few days.

[JeneralPain]

Hey Frank,

I think perhaps maybe we can setup a release schedule in GIT so that way we tie things to that specific process?

Jen

On Tue, Apr 18, 2023 at 5:36 PM frank-weinberg @.***> wrote:

Based on a suggestion by Danger Muffin on the WFTDA forums, I want to introduce a predictable release schedule:

(At the moment any aspect of this is can be changed if someone brings up a good reason to change it.)

• New Major versions will be released after WFTDA world championships with beta/prerelease versions available in the months before that.
• These releases will be numbered based on the year that contains most of the regular season they correspond to, i.e. 23.x, 25.x, ...
• Changes that could significantly alter workflows or that have a nontrivial risk of introducing bugs that affect a game will only be introduced in new major versions.
  • Exceptions to this can be made for changes that address major pain points like what we are discussing in #603 https://github.com/rollerderby/scoreboard/issues/603
• Minor versions that fix bugs and/or introduce minor features will still be released as they are ready.
• 5.0.x will be treated as the major version for the current season with the next release being numbered 23.12.

What I'm unsure about:

Where do we draw the line for including features right away. E.g. looking at #599 https://github.com/rollerderby/scoreboard/issues/599 (SK screen) one could say that this doesn't affect existing workflows at all as this screen can just be ignored. But it does bring the potential of completely altering the NSO setup, which would be a major change. I'd really like to hear opinions on that.

— Reply to this email directly, view it on GitHub https://github.com/rollerderby/scoreboard/issues/609, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI4RNRETXUZETL3XZ2XWNV3XBY77FANCNFSM6AAAAAAXCG7STA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[bullseye555]

Overall, I like the idea of a regular release schedule. It'll also give the regular uses an idea of when to expect new functionality

Where do we draw the line for including features right away. E.g. looking at #599 (SK screen) one could say that this doesn't affect existing workflows at all as this screen can just be ignored. But it does bring the potential of completely altering the NSO setup, which would be a major change. I'd really like to hear opinions on that.

IMO, I think the criteria should be based around changes to the software itself, with any changes to NSO processes not factored in. Features are going to be requested to make existing NSO processes easier - the uptake of that is going to vary Country-by-Country, Tournament-by-Tournament, and even League-by-League, all depending on the technological capabilities of the league and the members therein Explicitly for 599? This, to me, means that as it doesn't impact existing workflows (no one HAS to use it to make the Scoreboard function) it's considered a minor update and can be released when it's ready

[frank-weinberg]

changes to NSO processes not factored in.

That would defeat the purpose. People out there have gotten the impression that CRG has become a moving target - by the time they will have learnt how to use it it changed again requiring further learning. And while this is in large part a misconception it is in peoples heads and causing them to distrust the software and their capabilities of using it. In this situation even changes that make the software easier to use will not help acceptance as the fact that it did change again reinforces this perception.

[bullseye555]

Fair point. As someone who's not had those issues, it wasn't something that came to mind initially

[AdamSmasherDerby]

I definitely agree that numbering versions to correspond to the year of release is a good idea, independent of the schedule. It's much easier to conceptualize "version 2022" than "version 5" if you're not fully plugged in.

I can see the argument that maybe timing major updates to fall after the championship season is a good idea, since it gives the developers some predictability to plan their time. In that case, however, it would ALSO be incumbent on the organizations to give the developers plenty of notice for rules and policy changes in order to have them incorporated in the next season's release. (cough cough JRDA cough) :)

The only concern is that if the developers hold themselves "on call" during playoffs / cups / champs to squash any emergencies that come up during that time, they would then immediately find themselves facing the next release date, and that's a lot all at once. But I think that's a minor concern, and I think the releases are mostly robust enough not to need a lot of tech support.

[frank-weinberg]

I've updated the original post based on the idea rolling around the back of my head for a few days and external input.

it gives the developers some predictability to plan their time

Actually, as a developer it is easier to have a "release when it is ready" policy as I can just work on it whenever I have time and motivation and no one can blame me for missing a deadline.

The only concern

That's not a concern for me, as the bulk of the work (implementing new features) has to be done before the prerelease goes out. If there are a bunch of last minute fixes before the main release, something has gone wrong.

[admdikramr]

I believe that it is sufficient to say that the new version, i.e., v2024.x, will not release until "after 2024 Champs." It is less important for us to have a predictable release date, as it is to know that we only need to re-learn CRG once per season.

Historically the WFTDA has released rules and practice changes with at least a month of lead time targeting "Jan 1" for the effective date. So, a few months after champs, plus more time if needed, should addresses Smasher's concern. This could change if tournaments start popping up earlier than March.

[JeneralPain]

@frank-weinberg We've got a "Slack server" running that Brian setup ages ago, can you join that since you don't have FB and we have no other easy way to comms with you?

[frank-weinberg]

I've never used Slack. But I thought about setting up a discord as that is where I already communicate with Robin', our new UI/UX person.

[frank-weinberg]

V2023.0 is released, the release schedule is up on the wiki -> closing this.