Proposal for a Development Cycle Schedule

Discussion among members of the development team.

Moderators: Forum Moderators, Developers

Post Reply
User avatar
SigurdFireDragon
Developer
Posts: 404
Joined: January 12th, 2011, 2:18 am
Location: Pennsylvania, USA

Proposal for a Development Cycle Schedule

Post by SigurdFireDragon » March 21st, 2018, 4:36 pm

I’ve seen some interest in this sort of thing on irc/discord, so this is to get the ball rolling.

I think there would be significant benefits for the project to adopt a standardized release routine/ cycle/schedule.

One such benefit:
Provide clear expectations to the community at large, so it is easier for developers, umc authors, & players to support the development process.

Suggested Length: 1 or 2 years
The example below is synced for releasing stable in time for the winter holidays.
Given the current situation, something resembling a ½ year or 1.5 year would need to be used for 1.15/1.16 to sync with the winter holidays.


Example 1-Year Cycle:

X.Y.0-dev – starts when new stable branched off of master
Time for updating build systems, dependencies, library and compiler updates
Ie, anything expected to be significantly disruptive should be confined to this part of the cycle (exceptions for security fixes & the like)

X.Y.0 (First Alpha Relase) - First week of Feb or March?
Must be playable & sufficiently stable that most UMC authors & SP/MP players are willing to starting using it.

X.Y.0+dev - A stable enough experience to allow for all who are willing & able to build master to contribute via playtesting, bug reports, pr's etc.

X.Y.1 -> X.Y.? - Additional Alpha releases

Beta – First week in September or October??
String Freeze?

RC – First week in November or Mid October?
Feature Freeze?

Gold – Release New Stable – First week of December

Branch off New stable from Master – At RC 1 or after Stable is released??

Tad_Carlucci
Developer
Posts: 308
Joined: April 24th, 2016, 4:18 pm

Re: Proposal for a Development Cycle Schedule

Post by Tad_Carlucci » March 21st, 2018, 9:12 pm

I like even/odd cycles, too. Development versions are odd (like 1.13) and stables are even (1.14)

Branch at RC1 tag. The intent of a Release Candidate is that it be, as close as possible, identical to the actual release.

I would not have done 1.13.12. I would have branched and the two versions following 1.13.11 would have been 1.14.0-RC1 and 1.15.0-dev. If not further release candidates were needed, the version following 1.14.0-RC1 would be 1.14.0 itself. I suppose you could double-tag it as 1.14.0-RC1 (released) and 1.15.0 (unreleased) before proceeding immediately to 1.15.0-dev while 1.14.0 matures.

Personally, I like shorter sprints: 6, maybe 12 months. Two years is just to long. While we want to allow time for meaningful changes, we don't want to encourage overly-ambitious goals. A really massive change would be better broken into phases then running the risk of missing the scheduling commitments.

I agree, final release cycles should being near Yule. People will be more likely to donate their efforts when it's not so nice outside, and we want a bit of time after the start of the release for the RC to mature, translations to be updated, etc, before the weather turns nice and people would rather be outside than sitting at a desk.
I forked real life and now I'm getting merge conflicts.

User avatar
shadowm
Site Administrator
Posts: 6486
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Proposal for a Development Cycle Schedule

Post by shadowm » March 22nd, 2018, 1:55 am

@sigurdfd

Other than the fact that normally the string and feature freeze happen at the same time upon the release of beta 1 for the next stable (this time that wasn’t the case for reasons that are frankly unknown to me), this doesn’t sound all that different from regular business. The only real point of contention that there’s even been is that 1.9.x, 1.11.x, and 1.13.x all dragged out for much longer than anyone hoped for, when we were used to one-year release cycles before that (after 1.2.0 and until 1.8.0).

@Tad_Carlucci

You’re arguing semantics again. 1.13.12 is necessary because of the way we handle version numbers both in code and as people. We’re not discussing the format of version numbers here, we’re talking about the development schedule, so that is an unnecessary tangent.

Also, I’m going to remind you all that multi-RC cycles are not unheard of here, they have happened before (1.2 is the winner with 4 RCs, second place are 1.6 and 1.12 with 3 RCs), and they can and will happen again. That is not a bad thing by itself, it’s just a reflection of the QA situation as it evolves over time since the first RC, and it’s not a “decision” that can be “made” in advance, it just happens organically.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Elsewhere: shadowmBlogFollow me on Twitter

User avatar
Pentarctagon
Forum Administrator
Posts: 3543
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Proposal for a Development Cycle Schedule

Post by Pentarctagon » March 22nd, 2018, 5:13 am

The Linux kernel also has multiple RC releases, somewhat recently even up to 4.15-rc8. So it's not just Wesnoth that does this.
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
shadowm
Site Administrator
Posts: 6486
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Proposal for a Development Cycle Schedule

Post by shadowm » March 22nd, 2018, 5:20 am

The concept of Release Candidate they handle there is a bit more exotic, though. Usually a Linux release isn’t considered anywhere near stable until rc6 or so, and rc1 in particular contains all the breakage that follows the repository merge window at the very start of a new development cycle.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Elsewhere: shadowmBlogFollow me on Twitter

User avatar
SigurdFireDragon
Developer
Posts: 404
Joined: January 12th, 2011, 2:18 am
Location: Pennsylvania, USA

Re: Proposal for a Development Cycle Schedule

Post by SigurdFireDragon » March 24th, 2018, 3:50 pm

shadowm wrote:
March 22nd, 2018, 1:55 am
Other than the fact that normally the string and feature freeze happen at the same time upon the release of beta 1 for the next stable (this time that wasn’t the case for reasons that are frankly unknown to me), this doesn’t sound all that different from regular business. The only real point of contention that there’s even been is that 1.9.x, 1.11.x, and 1.13.x all dragged out for much longer than anyone hoped for, when we were used to one-year release cycles before that (after 1.2.0 and until 1.8.0).
I would like to see it be regular business again.

That makes sense, string & feature freeze upon Beta 1.
As that would make Beta be the ideal time for focused work on bug fixes, something that got more players to check out the beta version (instead of showing up en mass at RC1) might be helpful. Would starting the stable add-on server at Beta 1 make sense for this?

Post Reply