Future release schedule.

[namida]

Releases of new versions are subject to the following rules around timing:

1. After a major stable version (VXX.YY.0), the next major update's RC (VXX.ZZ.0-RC1) will not be released until at least roughly two months have passed.
2. After an update's first RC build (VXX.YY.0-RC1), the stable version (VXX.YY.0) will not be released until at least roughly two weeks have passed.
3. To be clear, these rules do not affect minor updates (VXX.YY.1, VXX.YY.2 etc) or RC updates (VXX.ZZ.0-RC2, VXX.ZZ.0-RC3, etc), which will be released as and when needed.

Former schedule

I created a topic a while back to talk about what the future release schedule for NL might look like. Since no one weighed in, I'm going to adopt mostly my original idea there. So, from now on, NeoLemmix updates will generally follow this schedule, with the updates happening by the middle of the month.

February: Even-numbered major stable release (V12.8.0, V12.12.0, V12.16.0, etc)
May: Odd-numbered major stable release (V12.9.0, V12.13.0, V12.17.0, etc)
August: Even-numbered major stable release (V12.6.0, V12.10.0, V12.14.0, etc)
November: Odd-numbered major stable release (V12.7.0, V12.11.0, V12.15.0, etc)

From now on, the even-numbered updates (V12.10.X, V12.12.X, etc) will be mainly focused on cosmetic features. The odd-numbered updates (V12.11.X, V12.13.X, etc) will be mainly focused on gameplay features, with cosmetic changes generally being limited to those that are necessary to support the new / changed gameplay features. UI improvements may occur in either, but will generally be more prominent in the even-numbered versions.

Minor updates will be released as needed, usually for urgent bugfixes or to implement things that were obvious oversights.

Styles updates for single styles can be uploaded at any time. The all-styles download is generally updated on a monthly basis.

The deprecation-to-cull schedule will be, where practical that at least three major updates keep a deprecated feature, then the fourth may cull it. This equates to a minimum of roughly 9 months between a feature being deprecated and the feature being culled (or in the case of a format change, the same time between the older format being deprecated and support for it being culled). For the purpose of this, only releases from V12.7.0 onwards will be considered - so the first version that could start culling deprecated features will be V12.10.0. In practice, I will likely leave the majority of deprecated stuff in place until the "final" version.

The only exception will be deprecated pieces in styles; for now these will remain indefinitely in official styles. It is at the author's discretion in the case of custom styles, but I suggest for consistency that style authors follow what the official styles do.

I will clearly elaborate on what's going to be culled in each release, and where possible, provide tools to auto-update content (eg. the deprecation of the "RELEASE_RATE" keyword in level files, this is something that a tool can easily automatically change the level files to use the "SPAWN_INTERVAL" keyword instead).

And I will stress here - if it would be really messy to keep backwards-compatibility, I might get rid of it sooner. I'll try to avoid this, but it may happen from time to time.



The other thing to consider is how experimentals will be treated going forward. I'm going to divide them into two categories - "Experimentals" and "Release Candidates".

The ones that will remain "experimentals" are builds that are released for the purpose of testing / discussing a specific feature. An example from the past would be the build Nepster released for Shimmier testing. These should be treated as unstable - don't build content that relies on them, the feature might not make it in, or might get significant changes. It's there for evaluating and bugtesting proposed features only.

The ones that will now be known as "release candidates" are basically beta versions of the new stable release. They need testing, they may need bugfixes, but they're close to stable. An example would be the V12.6.0 experimentals I released shortly before the actual V12.6.0 release. They can generally be used to update content or make new content for the upcoming stable release, as long as you wait for the stable release and test your content on it before releasing it publicly. Basically - while it's not outright guaranteed nothing will change or break between a release candidate and the stable build, it's intended that as much as possible will stay the same, and changes would generally only be to fix bugs or handle obvious oversights - pretty much, the same kind of changes that might be expected in a minor update to the stable release.

You're strongly encouraged to test out the release candidate builds. The more testing they get, the less minor updates will be needed later.



This only relates to the NL player and its styles. The editor will, for now, remain on an "updates released as and when ready" basis, although generally a major update to NL will be accompanied by a corresponding editor update.

[namida]

Coming back to this, I originally wrote this with the intention of it being to slow down releases - so that we don't have a new major release every couple of weeks, basically.

However, it's turned out to be little if any risk of this. Instead, the schedule is if anything putting too much pressure to rush releases.

As such - while I'll be keeping the "alternate between cosmetic / UI focused versions and physics focused versions" (at least until such time that there's no longer going to be any more physics changes other than bugfixes), I'm going to replace the schedule with only these three rules:

1. After a new major stable version (ie: V12.XX.0) is released, it will be at least two months before the next major update's RC build is released.
2. After the first RC build for a new major version (ie: V12.XX.0-RC1) is released, it will be at least two weeks before the corresponding stable version is released.
3. Time periods mentioned in rules #1 and #2 operate on an approximate basis. It may be that, for example, I release an RC build 1 month and 29 days after a stable release or something like that.