openmw.org

I won't be at work again this year except for Monday, so I'll have at least some time soon. That'll definitely disappear 2.

The forum has been somewhat silent what with Zini not being here to wrap things up, and with the 1 year window of 0.45 coming up next month it would be nice to see what the current status of the release process is for those of us not as involved in the development process.
From what I can tell of the action on the github it doesn't look like all points capo's checklist have been met yet, but which are remaining as blockers?
And what could potentially be pushed off to 0.47 to get the re-invigoration following a major release.

As another non-dev, I'd greatly appreciate any info that could be shared as well. For the past year at least, it seems Capostrophic and akortunov have been submitting practically all of the pull requests on git, with any issues assigned to other devs not showing progress. This isn't at all to ignore the contributions of many other devs over the years (e.g. AnyOldName's recent landmark implementation of shadows, which I'm enjoying with the latest nightly), but just to acknowledge that there's likely a good reason for the "delay" in the next release as the burden has been disproportionately on a handful of folks. Whatever the case, this remains one of the projects I'm most excited about, as it has been for many years, and there's great progress visible with every new bug fixed and feature added on git - you all are the best.

Zini is around... have a look:
https://github.com/OpenMW/openmw/pull/2 ... r376546460

There are still a few things that need to be tidied up before 0.46 release.

psi29a wrote: ↑10 Feb 2020, 09:51 There are still a few things that need to be tidied up before 0.46 release.

IIRC, the only blocker left is AnyOldName3's review for changes in the OSG-on-steroids.
Remember: a larger and longer release - a more errors in released code.

That really depends on how many people use nightlies. If most of your userbase is on nightlies, then there's already thorough testing of most changes, and a long release cycle means there's more visibility of potential issues before the release, but a short one means that the features the release brings are still in an early form. For example, if we'd done the 0.46 release six months ago, there'd be a bunch more problems with detour navigation and shadows than there are now.

AnyOldName3 wrote: ↑10 Feb 2020, 23:11 For example, if we'd done the 0.46 release six months ago, there'd be a bunch more problems with detour navigation and shadows than there are now.

From the other hand, we could find such problems faster due to wider testing and release the 0.47 or 0.46.1 with related fixes a couple of months ago.
I am pretty sure that there are more issues with shadows and navmeshes (and with other new features) which we did not find yet due to our limited hardware and modded assets coverage.

When we released 0.45, we still missed several regressions which were fixed in 0.46, despite a half-of-year RC phase.
These issues are still present in the latest stable release despite they were fixed about year ago.

Wait, is it not common knowledge 0.45.0 was released half-baked?

Anyway, trying to speed up 0.46.0 release just won't work out well. Especially if there are known issues. Nightly users aren't lab rats, but release build users are especially so.

Capostrophic wrote: ↑11 Feb 2020, 08:57 Nightly users aren't lab rats, but release build users are especially so.

Nightly builds are supposed to be used by testers to find bugs before they get into the stable release. When user launches a nightly build, he SHOULD be ready to encounter bugs which are not present in the latest stable release (and report about these bugs to make them fixed).
If end-users are forced to use nighlies because we have more than year of pause between releases (and because the latest stable release becomes obsoleted before its release due to long RC phase), it is our release system's flaw.
For example, 0.45 users still have no some patches from year 2018 (now it is a year 2020, if anyone interested).
Also when Scrawl developed OpenMW, he uploaded his patches directly to the master branch, without review and testing (remember situation with keyboard navigation?), and I do not remember any statements about lab rats there.

As for bugs in releases, there are plenty of them in different software even after it stops to get updates. OpenMW is not an exception here.
Main ideas:
1. Even long testing does not prove software to be a bug-free, so every our large (0.x or even 1.x) release will more likely provide new bugs anyway.
2. We should not afraid to make minor releases and hotfixes (0.x.y) to fix these bugs.
3. We should avoid huge releases since they are very hard to test, and developers start to afraid to make new changes to do not break something. As a result, development speed degrades and chance to do not find some regressions increases.
4. A side activity (release videos, release commentaries translation to deutch/russian/whatever languages) should not delay releases (since release delays lead as to huge releases, as in 0.45).
Yes, it may hurt a PR to do not have them, but delays hurt PR more a lot.
5. Nightlies (and master branch) are for testers ("lab rats", as some people call them for some reason), not for end-users. Users can temporary use a bleeding-edge code to workaround critical bugs in stable releases until we release a hotfix, but they should not use bleeding-edge builds in normal situations. If you do not want to be a tester, you should not use a bleeding-edge software (e.g. drivers betas).

A lot of things there are only true if you make them true. For example, Dolphin Emulator hasn't had a stable release for several years and doesn't intend to have another any time soon. Users are expected to use builds from the master branch, and CI artefacts from pull requests are the things for the lab rats. That works out fine while violating a lot of the things you said as fact.