Latest Posts

Topic: Widelands' Release Model

stonerl
Avatar
Joined: 2018-07-30, 00:03
Posts: 95
Ranking
Likes to be here
Location: Earth
Posted at: 2018-10-12, 01:34

This is something I'm scratching my had about for a while now. Over on launchpad I just noticed some disagreement about a feature/bug-merge, which finally got me to the point to write about this topic. As a side note; WorldSavior once asked me how the popularity of Widelands could be increased and more players be attracted. Ironing out bugs and make it easier to play online came to mind, also improving game-play and balancing. Lot's of improvements and bug-fixing has been done, but what is missing is... a release.

Build 19 is out since November 2016, almost 2 years. Between Build 18 and Build 19 almost 2 and a half years have past. This is way to much time IMHO and I see some problems with the current release model.

It simply takes to long to get new versions out, which has several implications: One is that users might think that development is stalled. But more important. bugs are more or less in the game even though they might already have been fixed in the development version. Which might result in players abandoning the game since they don't know when this very bug that bugs them the most will be fixed. Also new and matured features might have two wait for months/years before they are available to the players.

I, myself contributed some minor patches during the last months, and since I came to the party shortly before the not so distant Build 20, I'm quite happy to see my contributions available to the players very soon. But what if I would have participated after the release of Build 20? How long would it take until my contributions are in a "stable" build?

Maybe a fixed release schedule would help. Say for instance major release every 6 months, regardless of the new features, improvements and bugfixes that have been added to this point. If there are bugs discovered in between these major releases then there should be a bugfix release. Splitting development into 2 branches, e.g. bugfix-branch and feature-branch could help.

But this is something that needs to be discussed thoroughly. All I know is: after B20 is out the release model should be adapted, IMHO.


Top Quote
kaputtnik
Avatar
Joined: 2013-02-18, 20:48
Posts: 1523
Ranking
One Elder of Players
Location: Germany
Posted at: 2018-10-12, 08:28

This was discussed some time, but can't find it....

You pointed out valid reasons for a shorter release cycle and i agree to all of them.

But i think a fixed release schedule has some downsides:

  • A developer may get stressed close before the date of release
  • A major bug may do not get into the release, because the code is not approved

I think having a planned release cycle of one Year would be fine, without having trouble to release exactly after a year.

Or a Features fixed release cycle? Say if featureX and featureY is implemented and tested, lets have a new release. Such a release plan would keep the focus on the features...


Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 18:07
Posts: 297
Ranking
Tribe Member
Location: 0x55555d3a34c0
Posted at: 2018-10-12, 09:07

Ubuntu releases a new Short Time Support version every 6 months and a Long Time Support version every 2 years. Perhaps we could have something similar in Widelands: The "official stable builds" (b20, b21, …) are treated the same as now, and additionally every half year or so a "stable development version" is released (v20-1', v20-2', …). It would be clear that these stable-dev versions would not be as bugless as the official builds, but more stable than the daily builds (trunk).


Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-10-12, 10:08

Widelands is an open-source game, not a life-critical system, neither a customer-paid product. Therefore, the best release-model should be the one that brings the most convenience to everyone involved. In my opinion, that would be to have a minor release every time there is some major bug-fixing or some major feature-addition, meaning something that pushes the game's quality considerably forward. Those relatively frequent releases would be potentially unstable and without support. Then once in a while, the community as a whole would raise consensus for one of those releases to be considered stable enough to be promoted into the status of point-of-reference release, thus called major and provided with support.


Top Quote
einstein13
Avatar
Joined: 2013-07-29, 00:01
Posts: 1021
Ranking
One Elder of Players
Location: Poland
Posted at: 2018-10-12, 12:29

Probably we need to wait for GunChleoc who knows more about time and effort of creating a new release. I remember that there were several versions of b19, just because some new bugs were found. That contained replacing all the install files and texts around the launchpad and website.

If we want to have semi-builds for semi-official patches, that would bring us to better approach for players, but more work around deployment. How much more? I don't know.

And my opinion: I am FOR that change! Probably strict dates are not the best, but semi-official releases will for sure bring more players.

Also it will help with tournaments where we will have more "stable" rules for the games and easier way to see the replays.


einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 2626
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2018-10-12, 13:46

This is something worth thinking about after our move to GitHub.

I must admit I am a bit worried about having to port bug fixed to too many branches - at the moment, we have just 2 of them: development and 1 release.

What we might do is to use the tagging system in GitHub whenever we think that there's a state of the code worthy of being labeled as an intermediate stage.

I'd love to have yearly releases, but it always drags out for longer than expected. I have been mostly in bugfixing-and-bringing-unfinished-features-to-a-usable-stage mode since April, but then we also had hessenfarmer and Nordfriese come in with a new tribe and new scenarios that needed code changes, and I wanted to support them and enable them to be creative, resulting in further delays...


Busy indexing nil values

Top Quote
Tibor
Joined: 2009-03-23, 23:24
Posts: 1185
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-10-12, 14:52

Is it possible that some other person (not Gun) was responsible for such immediate releases? And based on his opinion he might "backport" some critical bugfixes into that intermediate versions - again without affectiing main branch and bothering Gun..


Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 18:07
Posts: 297
Ranking
Tribe Member
Location: 0x55555d3a34c0
Posted at: 2018-10-12, 15:10

I'd love to have yearly releases, but it always drags out for longer than expected. I have been mostly in bugfixing-and-bringing-unfinished-features-to-a-usable-stage mode since April, but then we also had hessenfarmer and Nordfriese come in with a new tribe and new scenarios that needed code changes, and I wanted to support them and enable them to be creative, resulting in further delays...

I apologize for inadvertently delaying the release!
Your support was most appreciated of course face-smile.png

By the way, I´m also contributing code, but as I just noticed I´m listed "only" for graphics, missions and the fri campaign in the developer list


Top Quote
kaputtnik
Avatar
Joined: 2013-02-18, 20:48
Posts: 1523
Ranking
One Elder of Players
Location: Germany
Posted at: 2018-10-12, 17:52

A good thing would be to clear GunChleaoc of charge, eg.:

Nordfriese wrote:

By the way, I´m also contributing code, but as I just noticed I´m listed "only" for graphics, missions and the fri campaign in the developer list

AFAIK you are a developer, so you can do that yourself face-wink.png Create a branch, apply yourself to the developers.json and propose for merging.

I saw also some approved merge requests, waiting for GunCheloc to write the 'magic words'. I one approves a merge request, he/she can write those words also. There is no need to be a Project leader to do so.

I am not convinced, that having semi-builds will bring more players. Especially if they are called 'not supported' or 'can contain bugs'. I think such builds will grow up maintenance, e.g. if a bug get reported several times and a dev has to mark them as duplicates. Those semi builds are the same as playing with current trunk, imho, especially since current trunk can be easily installed on both linux and windows.

Edited: 2018-10-12, 17:53
Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 2626
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2018-10-12, 22:24

Nordfriese wrote:

I apologize for inadvertently delaying the release!
Your support was most appreciated of course face-smile.png

Don't worry, it was worth it in my opinion face-smile.png

By the way, I´m also contributing code, but as I just noticed I´m listed "only" for graphics, missions and the fri campaign in the developer list

That's because you originally didn't venture into C++ - please do remind me if I forget, I'm on the wrong computer right now.


Busy indexing nil values

Top Quote