[Proposal] Standard Release Schedule

Discussion among members of the development team.

Moderator: Forum Moderators

gfgtdf
Developer
Posts: 1432
Joined: February 10th, 2013, 2:25 pm

Re: [Proposal] Standard Release Schedule

Post by gfgtdf »

This issue is very much about 1.15 since it defines what api changes should put in in 1.15 for the very reason i just explained: If we can add API features in 1.16, then i'd be rather reculant to accept new apis in 1.15 if i'm unsure whether its really needed or whether there is a really good usecase for it (meaning: delay the addition of a feature for in until a concrete addon really needs it, which will typically happen during stable releases). If we don't accept new api in 1.16 i'll probably more often then not accept a new api with a "Let have this in before we might miss it in 1.16" reason.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [Proposal] Standard Release Schedule

Post by Pentarctagon »

Right, but how strictly the usecase(s) behind new APIs are evaluated is distinct from how frequently there will be new 1.14 and 1.15 releases.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
User avatar
octalot
General Code Maintainer
Posts: 783
Joined: July 17th, 2010, 7:40 pm
Location: Austria

Re: [Proposal] Standard Release Schedule

Post by octalot »

gfgtdf wrote: July 15th, 2020, 2:26 pm most features, in particular when it come to the api can be added without breaking any code at all. In particular those that are of the type 'the c++ function already exists lets add a lua api for it' or forgotten properties of lua unit/side object are basicially guaranteed not to break old code.

Also i look at the 'breaking changes' is see really mostly 'intential' breaking since people disliked he old api (for a reason), Those changes would of course not be added to stable releases
What if someone wants to change the C++ function during the same development cycle?
  1. Someone adds the Lua API to the dev branch
  2. It's used by some UMC authors, but as an only-available-on-dev feature
  3. Now that it's being used, there's more attention on this functionality, which leads to a refactor of the C++ code or even a redesign
  4. The UMC authors that used it have to change their code, but it's limited to the few authors who knew they were using a dev version
Now add "2a. The Lua API is added to stable release X.Y.Z." Are steps 3 and 4 acceptable on the dev branch? Can the results of 3 and 4 be backported to stable?
gfgtdf
Developer
Posts: 1432
Joined: February 10th, 2013, 2:25 pm

Re: [Proposal] Standard Release Schedule

Post by gfgtdf »

Pentarctagon wrote: July 15th, 2020, 8:15 pm Right, but how strictly the usecase(s) behind new APIs are evaluated is distinct from how frequently there will be new 1.14 and 1.15 releases.
Okay i can make new thread for it. Maye you can then move relevant post over.

octalot wrote: July 15th, 2020, 8:25 pm
gfgtdf wrote: July 15th, 2020, 2:26 pm most features, in particular when it come to the api can be added without breaking any code at all. In particular those that are of the type 'the c++ function already exists lets add a lua api for it' or forgotten properties of lua unit/side object are basicially guaranteed not to break old code.

Also i look at the 'breaking changes' is see really mostly 'intential' breaking since people disliked he old api (for a reason), Those changes would of course not be added to stable releases
What if someone wants to change the C++ function during the same development cycle?
  1. Someone adds the Lua API to the dev branch
  2. It's used by some UMC authors, but as an only-available-on-dev feature
  3. Now that it's being used, there's more attention on this functionality, which leads to a refactor of the C++ code or even a redesign
  4. The UMC authors that used it have to change their code, but it's limited to the few authors who knew they were using a dev version
Now add "2a. The Lua API is added to stable release X.Y.Z." Are steps 3 and 4 acceptable on the dev branch? Can the results of 3 and 4 be backported to stable?
If understood your case correctly these changes acceptable for the dev branch only, and cannot be backported. But usually such cases are quite rare since for most of these cases its quite obvious what these function should do. And just because we can add features to a stable release it doesn't mean we will do so in a hurry without checking whether they couldn't be improved first. In fact i think quite the opposite is that case: going to stable will make it more likely that people think about what they add (instead of thinking 'this is jut dev, if is was imporfect we can still change it later' which then just doesn't happen)
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
gfgtdf
Developer
Posts: 1432
Joined: February 10th, 2013, 2:25 pm

Re: [Proposal] Standard Release Schedule

Post by gfgtdf »

So my thought on the stable release scedule:

First i want to say that i think that especially with the introduction of steam and the resulting reduced 'work' of users to install a new version we should definitely do it more often then we used to do.

In fact i think it does make sense to give steam users more and earlier releases, not only because it's less work for them to update but also because we can quickly fix it if we made a mistake. (i think we partly already do this)


To build my opinion i looked at https://github.com/wesnoth/wesnoth/commits/1.14 . It in particular contains three commit of myself, One introduces quite a bad bug (this was an incomplte backport of a dev branch commit). One fixed a game crash for chinese players. One fixed the bug introduced by the first one.


The crash commit, it's not as bad as the memleak earlier since it only effects certain users and only if they have certain addons installed. But it's still a crash and i think making users 3 months with a potential crash is too long.

On the other hand, we had two commit since the last 1.14 release https://github.com/wesnoth/wesnoth/comm ... 09bc635790 and https://github.com/wesnoth/wesnoth/comm ... c3c8c9914d that caused serious bugs, that we certainly don't want in a release. It'd be nice if we would be able to rate the 'riskyness' of commit and omit them from a release if they werent tested, say for at least two months, but i'm not sure whether that's possible.



For dev releases i'd really like to talk about what classifies as a 'emergency release'. For example wesnoth 1.15.3 does not run the Add-on WorlConquestII due to a bug in wesnoth.show_dialog . For stable releases this would sure need a emergency release, but for the +dev branch i really don't know.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [Proposal] Standard Release Schedule

Post by Pentarctagon »

gfgtdf wrote: July 15th, 2020, 9:11 pm For dev releases i'd really like to talk about what classifies as a 'emergency release'. For example wesnoth 1.15.3 does not run the Add-on WorlConquestII due to a bug in wesnoth.show_dialog . For stable releases this would sure need a emergency release, but for the +dev branch i really don't know.
I'd consider emergency releases to cover the following situations, for both dev and stable branches:
  • A security flaw has been found and fixed.
  • Any generally user-significant functionality causes a crash or otherwise becomes functionally unusable. For example, the bug I introduced that made it impossible to load a saved game would need an emergency release had it made it into the next point release, but generally crash bugs reported within any of the UMC aren't (and historically haven't been) considered urgent enough to need an emergency release (ie: #4991).
The reason being that even though the dev branch is expected to be more buggy, it should at least still be playable, otherwise it will actively discourage users (or at least UMC authors) from using it, which is already a long standing problem anyway.
gfgtdf wrote: July 15th, 2020, 9:11 pm On the other hand, we had two commit since the last 1.14 release https://github.com/wesnoth/wesnoth/comm ... 09bc635790 and https://github.com/wesnoth/wesnoth/comm ... c3c8c9914d that caused serious bugs, that we certainly don't want in a release. It'd be nice if we would be able to rate the 'riskyness' of commit and omit them from a release if they werent tested, say for at least two months, but i'm not sure whether that's possible.
I think it'd be impractical, since there's also the possibility that reverting a commit can cause other bugs. Better options would probably be to either (a) ensure the person submitting the change confirms they have done sufficient testing (whatever that is determined to be for any particular change) and-or (b) leave it on the dev branch for some period of time. Generally though, if there are reasons to think something has a high likelihood of causing problems, then those should be brought up and addressed prior to merging the code in the first place. Including unit tests proving the functionality would also be another way to address concerns of potential issues.
gfgtdf wrote: July 15th, 2020, 9:11 pm So my thought on the stable release scedule:

First i want to say that i think that especially with the introduction of steam and the resulting reduced 'work' of users to install a new version we should definitely do it more often then we used to do.

In fact i think it does make sense to give steam users more and earlier releases, not only because it's less work for them to update but also because we can quickly fix it if we made a mistake. (i think we partly already do this)
This is something loonycyborg and hrubymar would need to confirm, but I don't think the non-Steam releases take a huge amount of extra effort - the steps needed to create the updated flatpak, macOS dmg (aside from the image signing required by Apple), and Windows installer executable are actually done as part of different travis jobs in fact and aren't hugely complex or time consuming. So while having more frequent releases will by itself probably nudge people towards using platforms that support automatic updates, I don't think there's a strong reason to *not* continue putting all updates on SourceForge, etc.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
User avatar
Iris
Site Administrator
Posts: 6797
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: [Proposal] Standard Release Schedule

Post by Iris »

gfgtdf wrote: July 15th, 2020, 2:26 pm I agreem, but most features, in particular when it come to the api can be added without breaking any code at all. In particular those that are of the type 'the c++ function already exists lets add a lua api for it' or forgotten properties of lua unit/side object are basicially guaranteed not to break old code.
They can be added, indeed. However, that means that we end up with situations where an add-on won't work on an older stable version, and it's not always obvious to the player why unless the author goes out of their way to loudly explain the situation like I do. And let's not even get started with the issue of people being stuck with an older version because a) Linux distribution; or b) they don't use Steam and don't like updating software (trust me, I know too many people on Windows who fall under this category).

It would be nice if Wesnoth could make an educated guess and tell people to update if something breaks, but I'm not sure how we'd even go about implementing that without simply adding a mechanism that phones home to get the latest version number on startup and tell the player about updates (and how to get them for whatever unique distribution channel they are using).
Pentarctagon wrote: July 15th, 2020, 3:08 pm For development releases, I'd be fine with monthly or even twice per month releases (though the latter is probably a bit much right now), as long as the overhead for creating and uploading the updates to Steam/SourceForge/etc isn't a problem. We'd also need to streamline how the release announcements are created, but you had a proposal that would help with that as well.

My thought regarding having the string/feature freeze start at RC1 was that RC releases are essentially what will turn into the official new stable release assuming there aren't any further issues discovered, so that'd be what translators should target for updating translations.
Loonycyborg fully automates his workflow as far as I know. Can't speak for hrubymar though.

The RC phase is far too late for translators to start working on translatable strings. They need a bigger time window, which traditionally started with beta 1. Trust me when I say that it's easy to underestimate both the importance of translations and the amount of work involved in bringing them up to speed after a development series. Been there, done that.

(Source: was the Spanish translation maintainer for 1.6. Took over a dead translation, had to review a lot of existing stuff, etc. Not light work at all. Hence my understanding of translators getting frustrated with our workflow — just not the part where they decide to wait until the last minute to express their frustration.)
Pentarctagon wrote: July 15th, 2020, 7:51 pm At this point I'd like to keep this thread focused on establishing what we're going to be doing for 1.14/1.15 going forward. Can you open another thread for discussing whether to allow new API features into future (1.16+) stable releases? Keeping in mind as well that with the 1.16 release there will be another PM election.
Noted, but in the meantime I responded to gfgtdf anyway. :P
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
gfgtdf
Developer
Posts: 1432
Joined: February 10th, 2013, 2:25 pm

Re: [Proposal] Standard Release Schedule

Post by gfgtdf »

Pentarctagon wrote: July 15th, 2020, 9:53 pm This is something loonycyborg and hrubymar would need to confirm, but I don't think the non-Steam releases take a huge amount of extra effort - the steps needed to create the updated flatpak, macOS dmg (aside from the image signing required by Apple), and Windows installer executable are actually done as part of different travis jobs in fact and aren't hugely complex or time consuming. So while having more frequent releases will by itself probably nudge people towards using platforms that support automatic updates, I don't think there's a strong reason to *not* continue putting all updates on SourceForge, etc.
I am not talking about the work on our end here, i'm talking about users who have to go to the website, download the installer and run it.

This is actually work, firstly the file is ~400mb some user probably have to wait a bit to download, then you have wait to it to unpack etc. and if it then doesn't work because it contains a gamebreaking bug so that they have to do it all again, they will probably be really pissed, at least i think i would be. I think steam users don't have this problem because updating goes afaik mostly automatic. That's why i think it makes sense to make steam users updates a bit quicker maybe few daysand release it then on the website once it has been 'tested' for two days. (Of course we have to first test it ourselves, but we will probably never test is as good as the players) . Again i think we at least partly already do this, at least i remember the last time this was brought up in a discussion it tuned out that steam updates does happen quicker than the release announcement.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [Proposal] Standard Release Schedule

Post by Pentarctagon »

The announcements and the release being out of sync hasn't been done intentionally, and actually has caused some users confusion since they got a Steam update without any announcement of what the update was. Beyond that though, I don't think there's been such a quality problem that uploading to non-Steam platforms later would be needed - even the one emergency release that's happened with 1.14 happened well after the release would have been uploaded elsewhere and fixed long-standing bugs rather than something newly introduced.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [Proposal] Standard Release Schedule

Post by Pentarctagon »

I've updated the initial post to reflect what's been discussed and agreed upon so far.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
Post Reply