Also, before we can release 0.48 we need to be very clear about our intent for: Lua Documentation /API and OpenMW-CS ESM compatibility (and non compatibility)
So after experiencing how things went with OP/AG with 0.47 which allowed other things to come in: groundcover, a2c, lighting... ; perhaps we can try to keep this release smaller, tighter and polished for a faster development and release cycle. I wanted 0.47 but again we fell into a yearly release tying up loose ends.
To speed up releases, once the first of the major intended features is finished, that could signal a wrap up and an initialization of 0.49. just a thought, to keep things simple. Lots of smaller stuff will surely come along for the ride.
That was the intention for 0.47; but there was a lag with the amount of work that needed to be done to get OP in shape, especially when the original author went missing.
The hope is that the people behind these major features stay around.
Yes, it's much easier to update and maintain an already working feature than it is to make someone else's half finished feature work correctly for the first time.
Example: I have been observing the GamePad GUI pass hands recently and I'm nervous as to how that's going to land.
So I plan to add a bunch of NIF things (gasp) before too long:
1) Sort out TCB and Bezier interpolation woes
2) Use tangents/bitangents from the NIF file so that the normal maps for Oblivion and later games just work
3) Add a NiFogProperty placeholder to slightly improve the compatibility with models that use it to disable fogging
4) Maybe get in the rest of NIF branch (so basically include Skyrim texturing and physics definitions to make much more models load, but the physics won't work right).
Considering how 0.47 has now officially taken longer than 0.46 in terms of getting released, when the goal was to reduce the time to release, perhaps it's time review what happened and what to do next. I think this had mostly to due with the late-term addition of features that would resolve the primary pain points of our new distant static system (Object Paging). So we could have either launched 0.47 without these fixes; and moved on to 0.48 or waited. I made the decision that we would wait so that lighting would be fixed when "Active Grid" is enabled... fixing a long standing lighting problem in OpenMW as a whole. I think it was worth it, but this is a special case and we're in a much better position now to just say "no" to feature creep.
We also have a much better CI and release building infrastructure and have many more testers involved that are still helping in the 0.47 RC phase.
We have pulled the trigger on further development and have now merged the initial Lua framework for 0.48; at this moment we're waiting on the final bits to fall into place for reverse-z for our graphics pipeline. In the mean time we've had lots of bug-fixes and long-standing issues being closed by our growing development team (both new and re-joining members). We are in a really good position here to say that after 0.47 is officially released, that we can start the 0.48 RC process which means:
* smaller release
* less work for our PR team
* hopefully smaller RC process due to smaller amount of changes
Which translates to faster release cadence. This is especially important now that we're asking for feedback from the community about our Lua API. A smaller, yet quicker release cadence is probably a good thing moving forward so that Lua modders won't be left in the cold by either targeting a 'stable' but old release or a 'bleeding edge' nightly/daily that could have their API changed out from under them. So let's meet in the middle.
We still have a bit of time to wrap things up, but if the VR side of things aren't ready by the time reverse-z is finished; I think we can pull the trigger and keep VR for 0.49;
psi29a wrote: ↑25 Jul 2021, 21:06
We are in a really good position here to say that after 0.47 is officially released, that we can start the 0.48 RC process ...
[...]
This is especially important now that we're asking for feedback from the community about our Lua API. A smaller, yet quicker release cadence is probably a good thing moving forward so that Lua modders won't be left in the cold by either targeting a 'stable' but old release or a 'bleeding edge' nightly/daily that could have their API changed out from under them. So let's meet in the middle.
This sounds great to me.
Regarding VR, we could basically do the same again when VR arrives if it does not arrive in time for the RC-phase of 0.48. Just start the RC phase for 0.49 as soon as VR is merged and make it yet another small release with one very major new feature.
Object paging was big, so obviously took it a while to finish regression hunting, but with smaller features like the alpha testing rework and async physics we were still fixing issues in the RC stage. If releases get too close together we'll miss regressions, so will need more time feature-frozen to keep attention on the RCs, and then risk killing developer interest if we spend too much time in feature freezes. We need to be careful with this. I'm pretty confident we can get to two releases a year without problems, but think three will be risky, and four's right out.
Early on, the features were simpler and interacted with fewer other features, so they had less chance of landing broken, and had less chance of breaking other things. They wouldn't have needed as long to mature.
