About the feature sets of devbuilds and release schedules

Here, developers communicate stuff that does not go onto the main News section or the front page of the site.
[Dev Blog] [Development Builds] [Git Change Log] [GZDoom Github Repo]

Moderator: GZDoom Developers

User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

About the feature sets of devbuilds and release schedules

Post by Graf Zahl »

Due to the spotty release schedule it has become common practice to base ZDoom projects on devbuilds, essentially taking for granted that once a feature was in it was final.

I don't think I need to emphasize that many times this caused problems because the engine got stuck with features that got prematurely exposed and could not be removed again.
So I think it is time to actually define an official policy about this.

I do not plan to continue the ZDoom release schedule. My personal idea of this is to do more frequent releases, at least two minor revisions each year with point releases to address bugs in-between. I already did so with 2.3.1 and 2.3.2, both of these releases are based on 2.3.0 and only contain the actual bugfixes since the first release but not the newly added features.

For the master branch the devbuilds are based on this means that it may switch between two different development styles - feature implementation and release preparation. The current state is clearly feature implementation, and the nature of this means that I may decide on short notice that some code needs to be disabled or removed. I will announce once I switch to release preparation.

While it should be perfectly fine to develop a new project based on devbuilds, anyone doing so has to be prepared to make a change to their project, should such a breaking change happen in the engine. What should be avoided is to release a project to the public which requires a devbuild to run. In that case you should better wait until the next release, even if you have to wait for a few months with the release then. I can not and will not address problems that come from releasing a devbuild-based project if it breaks between its release and the next official version. Doing so would make it impossible to undo things that later turn out to be a hindrance to engine development.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Nash »

How about a huge and annoying warning when the executable starts that states that devbuild features are subject to change and modders shouldn't rely on it for production, and be prepared to make changes when the engine changes?

Then for release builds, disable that warning.

This way, if a modder ignores the subject-to-change wanring, it's entirely his fault.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: About the feature sets of devbuilds and release schedule

Post by Graf Zahl »

I think that is overkill and will only discourage users.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Nash »

Okay so a huge and annoying warning would be exaggerating it - I think some purple/pink text on the console startup like the -zscript message back then would be enough.

I mean, if you want to educate modders, you'll have to plant your feet in the ground sometimes, since you are the one who's going to do the heavy-lifting code maintenance work, and you want to avoid coding in crutches for broken features, so...
User avatar
Caligari87
Admin
Posts: 6174
Joined: Thu Feb 26, 2004 3:02 pm
Preferred Pronouns: He/Him
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Caligari87 »

Just throwing my own vote, I think a console startup message should be sufficient. Even if a modder ignores it and releases against a devbuild, you can point to it later if they complain about broken features.

8-)
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Enjay »

I think a message (even a small one) is unnecessary and obtrusive. Graf's policy is entirely reasonable. I fully agree with and support it.

If people decide to do something like base their work on an as-yet not officially implemented feature, it's their loss if their mod breaks. Let's not forget, such modders have sought out and decided to work with a dev build rather than use the official release so they should know what they're dealing with.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: About the feature sets of devbuilds and release schedule

Post by Major Cooke »

It's even more their loss because they didn't bother to read a very highly categorized and separated piece of news. People think dev blogs are for rambling? HAH! This will show them just how terrible of a mistake it is to skip out on it.
User avatar
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Rachael »

Such people are also either rejecting or not understanding the policy of devbuilds in the first place: They were never meant to be a ground upon which you release mods. Ever.

It's understandable that it happened though - but infrequent releases will do that. I tried to look for a "mission statement" or some other kind of thing where I made that clear, but I guess it was that long ago that I was never truly that organized and task-oriented. :P But I know I made many posts stating something to the effect of exactly what Graf just iterated - minus the infrequent release schedule and his roadmap (which with ZDoom was a problem even in that time).

People really need to start paying attention to this. Betas never are releases nor are they ever meant to be. Perhaps we should state something to the effect in the official project guidelines? (Not an actual rule, per se, but something you can remind potential project posters about when they do it)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: About the feature sets of devbuilds and release schedule

Post by Graf Zahl »

It should also be noted that a long time ago we had such a breaking change between a 'beta' and the final release, and that was in 2.0.96x, when the CustomInventory states were part of the common Inventory class, but that was rejected by Randi, so the final version introduced CustomInventory (which in hindsight was an excellent thing because otherwise we now had a real problem with state owner mess infesting the entire inventory system.)
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Enjay »

Yup, I fully agree with the points made by Major Cooke and Eruanna and, of course, Graf's example is an excellent illustration (from the classic era of betas and unofficial builds from when the potential for this kind of thing first arose) of the kind of situation that can occur, the kind of problems that can result and, equally, the kind of problems that can (and will) be avoided by the policy in the original post in this thread (i.e. the freedom to change the implementation between beta and final release to ensure a better and future-safe piece of code).

If a modder bases their mod on an, as yet, unofficial feature from a dev build and feels entitled that it should work the same way in official releases, they are wrong. If they do make such a mod, they may have tied their release to that unofficial version, ignored the principle of beta testing, ignored the warnings and disclaimers on the DRD site and ignored Graf's clearly stated policy. I really don't think there should be yet another warning in the exe. The infrequent release 'schedule' (i.e. there wasn't really a schedule) did encourage such behaviour because the use of new features would have gone unrealised for months, if not years, if modders waited for official releases. However, this should no longer be the situation.

If any modder has a particular reason for releasing and saying "mod requires dev build from X date" (and some people still might) then they should also be prepared that they may have to update their mod when an official build comes out or end up with a broken mod in the future. i.e. modder's own risk applies in this situation: their choice, their fault if it breaks and there is plenty of information out there to ensure they know that.

However, it's worth recognising and reiterating that the 'need' to make mod releases with features that have only appeared in unofficial builds/betas should be very much reduced if not eliminated entirely given Graf's intended more frequent release schedule. I'm certain that we will all benefit from that.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: About the feature sets of devbuilds and release schedule

Post by Major Cooke »

For once, the TL;DR shield can finally be broken. And so will those who use it because of laziness.

I'm looking forward to the moaning and gnashing of their teeth... :twisted:
User avatar
Xaser
 
 
Posts: 10772
Joined: Sun Jul 20, 2003 12:15 pm
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Xaser »

Whew, it's about time that dev builds start acting like dev builds. Hopefully it'll be enough to discourage another DRPG scenario.

Half a year between releases sounds maybe a bit conservative, but I'm basing that on the latest period of extreme activity (holy zscript-in-a-couple-of-months, Batman!), and the pace will inevitably slow down in the future.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Matt »

Enjay wrote:I think a message (even a small one) is unnecessary and obtrusive. Graf's policy is entirely reasonable. I fully agree with and support it.

If people decide to do something like base their work on an as-yet not officially implemented feature, it's their loss if their mod breaks. Let's not forget, such modders have sought out and decided to work with a dev build rather than use the official release so they should know what they're dealing with.
This.

(a small unobtrusive message might be useful as a reminder for some of us as to which subject-to-change thing we might've broken, but it's probably more trouble than it's worth and if you need a console message to notice something might be amiss it's probably not broken at that point anyway.)
Blzut3
 
 
Posts: 3144
Joined: Wed Nov 24, 2004 12:59 pm
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Blzut3 »

One thing I would suggest adding to the release schedule, especially since we have a number of outside contributors, is a set hard feature freeze. Given that "2 minor releases" basically means 6 months give or take circumstances, I don't think it would be unreasonable to just have a hard feature freeze happen some defined amount of time, say 5 months, following the previous release. What this allows is for a defined release prep time where it's clear to contributors that no feature PRs will be merged.

For those asking for a message on start up. Honestly given the number of warnings I've seen mods spew, the truly problematic people won't notice it. I also really don't think it's necessary to make the dev builds different from release builds for a problem that should solve itself within a few releases. The disclaimer on the dev builds page could, however, add a link to this thread in a slightly obnoxious way to make sure everyone has the opportunity to be aware.
User avatar
Rachael
Posts: 13531
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: About the feature sets of devbuilds and release schedule

Post by Rachael »

Honestly, 5 months is a bit long for a feature freeze. ZDoom has proven to be a stable enough platform and does not have the same requirements as Zandronum does with stability. For the most part, if you're careful (i.e. more careful than me) you can avoid most crashes and fatal errors. I think 1 month is a generous amount of time for a feature freeze to pull things together and make sure it stays stable for launch.
Post Reply

Return to “Developer Blog”