Stable Release (0.H) candidate: your guide to the upcoming stable version

[I-am-Erk]

Announcing H-stable release candidate

We're going to be doing our release cycle differently this time, after numerous complaints and some attrition from contributors over the frustration of the feature freeze process. For 0.H Stable, we are going to try out a release candidate branch process, as is more commonly done in the IT industry (or so I've heard anyway, I really have no idea!)

The candidate branch for 0.H is the aptly named 0.H-branch. This is forked from experimental as of 04 January 2024. This is not the stable release, yet! We still have to merge fixes to the release blockers, collect reports and fixes on other breaking bugs, and all the usual smoothing out steps.

No freezes

There will be no feature/content/string freeze step for the experimental branch this time around. In some ways, it should remain Business As Usual in experimental, but I'd like to encourage mergers to slow down on merging major features and content to experimental while we figure this out, to keep backporting from being too much work. Contributors, likewise, might want to spend a little more time polishing and completing their major feature PRs rather than pushing them to merge right away. This is a recommendation, not a rule.

How to help

• Contributors can help best by focusing on bug fixes and completing unfinished content in the stable branch, rather than setting out on your new favourite project. We're all contributors on the dev team too, and I totally understand that you might want to keep working on whatever it is that strikes your passion. That is okay. The whole point of this structure is to allow people to keep doing that. However, we'd love it if you could find a little extra time to help patch and polish the stable branch, if you can.

• Players are strongly encouraged to play the H-stable candidate instead of experimental; once we're publishing regular releases of it, I'll link them in this post. We should also try to get them linked in the popular launchers. The biggest loss that this new structure has for us is that a lot of people are going to likely just keep going on experimental, which means we won't get playtest reports on what needs fixing in the stable candidate as much; more focus will, as always, be put into whatever new features are going into I-experimental. Of course, as above, the whole point of this structure is that you can do whatever you want, but if you want to help out and can't contribute, running a few games in the stable candidate and reporting on bugs will be indispensably helpful.

• Translators and tileset artists are even more strongly encouraged to work only on the stable branch. It's not going to be changing as fast and should therefore be easier to catch up on, which will lead to a much more complete stable release. (We are still working out the details of how translation will work. Expect updates shortly)

The Stable Backport process

PRs to be merged to the H-stable branch will be tagged with the 0.H Backport label. When these PRs are merged to experimental, they need either a same-time or follow-up PR to also merge them to stable. We're working on implementing a bot that should create these PRs automatically.

In the (probably unlikely) case that you have a fix that only applies to stable, you can of course just push changes to that branch instead of master.

What to backport

This is going to be a lot more stringent than our usual stable process, because we don't have to work on freezes.

1. New features should not be backported unless expressly cleared by someone like me or Kevin. I can't think of anything off the top of my head that would justify this. We're done adding new features to stable.
2. Changes to features should only be implemented if they fix a problem or severely incomplete portion of that feature.
3. Bugfixes are cool. Most bugfixes are likely to be fine to backport.
4. Optimizations and infrastructure improvements should only be backported if they make quite a significant difference to the game.
5. New content is the fuzziest area. Standalone new content, even minor content, should not be backported. However, content that completes existing material, especially material newly added to stable, is cautiously allowed. This can be a very blurry area: for example, I could make an argument that adding details and content to oceans is completing a new stable feature - but I do not currently plan to backport that PR.
6. Fixes/adjustments to existing content should be audited carefully. Anything that changes translation strings is going to delay stable release, so is better avoided (typo fixes etc are always fine). Balance changes, such as adjusting item weights or spawn chances etc, is more likely to be fine as long as it's well vetted.
7. Routine translation and tileset updates should proceed as usual. Tilesets in particular should be backwards compatible, so we can backport everything. Translation management will require some input from those who know more than me about our workflow there.

Expected outcomes

I think it's likely that H-stable is going to come out a bit less polished than previous stables, but the flip side is that this may be a faster release process, and not having a freeze is going to help a lot with contributor retention. I have my fingers crossed.

If you have helpful knowledge about how we might streamline and improve this, feel free to comment.

[Rabadash94]

I'm not sure if this is the right place, but... what is version 0.H going to be called?

[I-am-Erk]

That usually doesn't get announced until the final release is out :)

[Inglonias]

Is there going to be a place to download compiled binaries of the release? I can't imagine asking people to compile the branch themselves will lead to much testing.

[I-am-Erk]

Yes. It just hasn't been set up yet.

[Rabadash94]

#70056 will be complete at 0.H Stable?

[I-am-Erk]

No, definitely not. If we're lucky the first version will be in for 0.I

[reinerh]

Is there going to be a place to download compiled binaries of the release? I can't imagine asking people to compile the branch themselves will lead to much testing.

For Debian users the 0.H release candidate is now available in the experimental repo.

[kevingranade]

This issue has been mentioned on Cataclysm: Dark Days Ahead. There might be relevant details there:

https://discourse.cataclysmdda.org/t/easiest-way-to-install-0-h-rc1-on-devuan/29164/1

[realmanbroyder]

How can I download the trial version?

[Jan-Blasiak]

I hope LIXA gets included.

Whoever done work on that thing should get a complementary hotel soap packet, shit's stellar!

[Procyonae]

Standalone new content isn't being backported so no, chichit1044 and DPavonis made it tho if you want somewhere to send that soap packet.

[Procyonae]

How can I download the trial version?

The latest builds are available here https://github.com/CleverRaven/Cataclysm-DDA/releases?q=0.H+release+candidate&expanded=true now, they might show up on launchers too

[ER-95]

No blockers, so why no release yet?

[NetSysFire]

1. There are still backport PRs remaining
2. The changelog has to be written
3. Credits must be updated for 0.H
4. Probably also some last testing to catch bugs

Would you like to help? Nothing except point 1 needs technical knowledge, its just a chore.

[ShuCuoMao]

Anybody still working on that carbon steel?It's just pigeonholed and leave us a inadequate 3-tier equipment of mild mid and high steel

[Procyonae]

If peeps with 0.G stable saves could backup their saves and try updating to 0.H RC and then post a txt document of their copied errors (just press c) like errors.txt here that'd be cool as a last push so peeps have to ignore less stuff