About the feature sets of devbuilds and release schedules

[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.

[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.

[Graf Zahl]

I think that is overkill and will only discourage users.

[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...

[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.

[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.

[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.

[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. 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)

[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.)

[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.

[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...

[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.

[Matt]

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]

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.

[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.