Skript Release Model

[ShaneBeee]

I wanted to open a discussion regarding Skript's release model. This discussion is mainly for the dev team. I'm only publicly posting it here as this is going to be a big issue, and is easier to track than having this on discord.

Current Model

The current model for releases seems heavily flawed, and this is mainly our own mistake. As of right now the latest "stable" release, 2.4.1, was released on December 22/2019. This was 9 months ago. Since then we have had a couple handfuls of alpha and beta releases for 2.5.
The original intention for this was 2.4.x was going to continue getting bug fixes, all the while 2.5 would be getting new features, etc. We kinda crapped the bed there, as bug fixes were all being done on the 2.5 (master) branch. Im guilty of this too.

The main downfall here is our consumers are not seeing a decent amount of stable releases. 9 months since our last stable release seems a little overkill. Obviously 2.5 has had a LOT of work done on it, but in reality an update to Skript shouldn't be so large, that it takes 9+ months to get a stable release out.

Another downfall is the consumer wants updates, wether it be because they want new features, or its because the alpha/betas contain updates pertaining to a Minecraft update (ie: updated aliases, entities, biomes, effects, etc).

According to bStats, the majority of our consumers are using a 2.5 alpha/beta build (around 48%):

Even though we have warned users not to use these builds on production servers, it's clearly happening, since 2.5 has some cool new stuff, some really big bug fixes and more importantly, updating to work on current Spigot/Paper releases along with updated aliases/entities/etc.

In Summary

The current model is definitely not working in our favour, due to extended release times between stable releases.

Future Model

This will all be suggestion. I am in no means in a position within this team to declare what we WILL be doing, I am only suggesting an update to our current release model.

Frequency

I would like to suggest to amp up our frequency of updates. This can be done by changing how we update. Ex, rather than having nearly a year between updates, because we are focusing on BIG FEATURES, small features, bug fixes, etc all in one giant update, we break this up.
(main.major.minor)
I suggest our "major" updates focus on really big features, or at least features that heavily change how Skript works, and/or could potentially break a lot of things, ie: not just new expressions/conditions/effects/etc.
A good example would be APickledWalrus' persistent data system, or my parse if system. These are clearly big features that need a lot of testing/feedback as they could potentially break a lot of stuff.

Our "minor" releases should focus on small changes, such as new expressions/effects/events/conditions/etc which typically won't break anything, as well as bug fixes, and updates regarding Minecraft (ie: new entities, aliases, etc).

This way, as an example, we could release 2.5 (hopefully soon), and start working on 2.6. 2.6 being our "big update" with "big new features" (ie: persistent data).
While 2.6 is in the works, we can continue adding some small new expressions/effects/events/conditions/etc, bug fixes, MC updates as minor releases (ie: 2.5.1, 2.5.2, 2.5.3). And the frequency of these should be more often.
In my opinion maybe no sooner than 2 weeks before updates, but if can be, no later than 1 month between updates (this will obviously depend heavily on what we are currently doing to said branch).

This will ensure the community is using "stable" release of Skript, and we can keep them updated and current.
All the while, we can continue working on 2.6 (or future updates at the time) which focus on big features, without feeling rushed to get builds out.
But at the same time, our consumers are getting new updates, new small features and bug fixes, more frequently, in our 2.5.x model.

I also feel that these BIG updates, like 2.6, shouldn't really have an alpha cycle. With the nightlies in actions, and hopefully more frequent updates, we shouldn't worry to much about alphas. We should focus on internal testing, and once we feel the big update, 2.6, is feeling good, we can/should start releasing betas for the public to test/give feedback.

Branches

I feel like one of the reasons we messed up with 2.4.x was due to how our branches are setup. Currently we have a 2.4 branch, while "master" is 2.5, and focused on a major update. This is not only confusing internally but also confusing to the community.
People whom fork Skript are thinking they're getting a roughly stable build in the master branch, possibly unknowingly using a potentially unstable branch.

Here is what I would like to suggest for a branch model, following the suggestions above:
MASTER - the master branch should focus on "current/stable" release. (this is obviously after 2.5 is released)
dev/2.6 - this branch can be used to work on the future 2.6 version of Skript (as master updates, merge into this branch to keep it up to date)
dev/2.5 - this branch can be used to work on 2.5, including bug fixes, new expressions/effects/etc and Minecraft updates, before release. Once we are ready to release (ie: "Oh hey we got some good stuff, let's do 2.5.1 soon"), we can at that point merge to master and push a stable release. IF we feel we need to do a beta release from this build, we can do so, without touching the master branch.

Summary

Our current branch and release models are not working in our favour, and need a little love.

Thank you for reading,
ShaneBee

Make Skript Great Again

[fednelpat]

It is time to make Skript great again

[bensku]

Sounds good to me. Having stable releases does little good if they're not actually maintained. Without backports for bug fixes, 2.4 could very well be less stable than current "beta" releases.

That being said, the original reason for introducing this branch model was rather... variable stability of Skript releases in 2.2-devX days. The situation has clearly improved since, but underlying reasons are still valid: Skript is easy to break and lacks a comprehensive automated test suite.