Planning a schedule for future releases

Started by namida, August 18, 2019, 10:04:08 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

namida

Okay so - I'd like to get into a system of having a more structured release schedule, so content creators can have a better idea of whether it's worth waiting for a certain feature or whether it's better off to just go ahead without it for now, as well as plan for when they might need to make modifications to their content, and so on.

My initial proposal here, is that:
- Minor updates, eg. V12.6.0 to V12.6.1, are made as needed. These will generally only be for bugfixes, or to implement things that were really obvious oversights (such as the shimmier skill shadow).
- Experimentals for specific features are made and released as needed. These should generally be treated as "for testing / debug purposes; physics / etc may change, be very careful about creating content that relies on specific details". They'll also more often than not be closer to the previous stable release than they are to the upcoming new release, except that they include the specific experimental feature.
- Major updates, eg. V12.6.0 to V12.7.0, are made roughly three months apart from each other.
- Release candidates for each major update will be released about a month beforehand. This release candidate can be treated as "almost stable" - basically, no intention exists to make further significant changes, but it still might need more testing and bugfixes. You can use it for preparing your content for the update; just make sure to double-check the content when the stable release arrives. Basically - it's expected and intended, but not guaranteed, that anything that works in the release candidate will also work in the stable release. I will be using the name "release candidate" here to better distinguish it from the typical experimentals (as described above).
- Additionally, the even-numbered updates (V12.8.0, V12.10.0, etc) may only introduce new (or significantly changed) cosmetic or UI features. The same rule will apply to any changes to physics, except where it's fixing bugs or edge cases in recently-introduced physics - these may come in the even-numbered updates (or if they're particularly urgent, even in a minor update). The odd-numbered updates (V12.7.0, V12.9.0, etc) may introduce / significantly change both cosmetic and physics features. (Of course, I'm not going to change things just for the sake of doing so - they "may" have changes, not they "will" have changes.)

This means that cosmetic or UI additions / changes may occur every 3 months, while physics additions / changes will only occur every 6 months. Of course, these will be guidelines - if there's a really good reason to get a major release out more urgently, I'll do so. Or if there isn't enough new stuff to justify one, it might be longer until one occurs.

What do people think about the above ideas? (Maybe 3 months is too frequent...?)
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

QuoteThe same rule will apply to any changes to physics, except where it's fixing bugs or edge cases in recently-introduced physics - these may come in the even-numbered updates (or if they're particularly urgent, even in a minor update).

To elaborate a bit on this, with some examples, let's say...

A new skill or not-purely-cosmetic object type is added. - This is a new physics feature, so it would need to come in an odd-numbered major update.
A decision is made that a certain skill will no longer be affected by blockers. - This is a change to a well-established detail of physics, so it would need to come in an odd-numbered major update.
An edge case is discovered with a newly-introduced skill where, under a very specific and obscure setup, something happens that seems illogical and it's decided to change it. - This is a change to a recently-introduced aspect of physics, but is not likely to have a significant impact for content so is not super-urgent to get fixed. It would be fixed in the next major update, whether that's odd or even numbered. Note that if the same thing happened with a skill that hasn't had physics adjustments in ages, it would likely be held back until an odd-numbered major update.
An edge case is discovered with a newly-introduced skill where, under a setup that's likely to occur very frequently, something happens that seems illogical and it's decided to change it. - This would very likely be a candidate for a minor update.
A serious glitch is discovered with a newly-introduced skill. - This will definitely call for a minor update to fix it.

For the avoidance of doubt, all of the above scenarios are examples only. In particular, no, there are no plans at this point in time to make the digger immune to blockers. (On the other hand, there are plans - eventually - to make it more visible when a digger gets affected by a blocker.)
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)