Change version numbering and other related things

[bensku]

Skript's current release system is not ideal. In case someone doesn't know, we have

• Development releases: usually quite stable, but sometimes utterly broken
• Nightly builds: broken more often than not, plus no changelog available

Release Numbering

I suggest the following scheme: MAJOR.MINOR.PATCH

MAJOR: new, breaking changes, or a huge amount of changes
MINOR: new features, bug fixes, no major breaking changes
PATCH: only bug fixes, no new features, absolutely no breaking changes

Code Organization

Most of Skript development, including pull requests, targets next MINOR release, and goes into master branch. If particularly breaking changes are put in, that MINOR release might transform into a MAJOR one.

Each MINOR release gets its own branch. Until next MINOR or MAJOR release comes, all bug fixes should be done in that branch, then immediately merged to master.

Feature branches (aliases-rework, for example) do not likely need any chances. The developer who has a feature branch can work pretty much however they want in that branch. It'll be merged to master when it is ready, as would happen currently.

Creating a Release

When a new MINOR or MAJOR release is somewhat ready, it will get its own branch, which tracks master. No new features should be added to that branch. Instead, a beta release should be created from it. If there are (serious) bugs, they should be fixed, and after that, new beta release should be created. When no new breaking bugs can be found from a beta release, it can be promoted to stable release.

Development releases from master branch can probably work as they do now. Their userbase will likely shrink significantly, since most people seem to prefer (apparent) stability of old Skript versions even now and would likely update to stable Skript versions instead.

Nightly builds can probably continue as they do now.

Transitioning

Next stable release has been labeled to be 2.3. However, the amount of changes since 2.2 is quite insane. Number of breaking changes is low, though. At least I hope so. We should consider making it 3.0, but that has its own problems too.

Challenges

Publishing stable releases does require that they are, in fact, stable. We need to test them more than current dev releases.

Github releases page is not be ideal for distributing beta, stable and development releases. Users might find it confusing, not knowing what to download. On the other hand, it requires no maintenance.

Everyone, please comment. What do you think about this idea? Would it be improvement over current situation?
@SkriptLang/developers @TheBentoBox

[abandonedaccount6235]

I don't see the benefit of the proposed setup, it just seems like the current one but with more steps and a mess of branches after a couple releases. I've never had a problem with the current setup where everything is developed and released in the hopes of eventually leading up to something that can be considered a stable release.

edit: I like the release numbering though

[TheBentoBox]

The part of this that I most want is for us to actually start using version numbering. Eternally counting up with dev releases effectively makes the dev build number our version number, which is kind of awkward and personally harder to remember than standard version numbering. I'd like to see versioned feature releases more often, such as the upcoming 2.3. After that, it'd be nice to see us have a general goal for stuff to add for 2.4, with progress towards it once again being made in dev releases which are versioned towards the upcoming release (e.g. the first dev release for 2.4 after we release 2.3 would be Skript 2.4-dev1 because it's a development release of 2.4).

Branching is more up to you guys as the developers. I agree with Pika that a mess of branches isn't good, but IMO there's value in moving towards having a separation between bug fix patches for the current release and changes/additions for the next release (be it dev or otherwise). It's really bad that bug fixes are always relegated to the next dev release, which often requires resolving other issues and can take days/weeks as a result. This would mean having a dev branch where features for the next release (currently 2.3) would reside (non-bugfix PR's pulled into there and dev releases and nightly builds built from there) while bug fixes could go to master and then patch releases could be built from there.

[Snow-Pyon]

I do agree with Pikachu and Simba, the suggested code organization sounds a bit messy and a bit annoying to work with. I would rather have a development branch and having "sub-branches" with it containing the features/bugfixes to be added and then merge everything to master when done, I would also like to suggest the usage of PRs for releases with this since it is overall more organized and allows us to test whether everything works as expected before actually releasing a new version.

As for the version numbering choice, I totally agree that we should use semantic versioning again, the current one is just not good.

[bensku]

I suppose new branch would not be needed for each release. We could have a single branch, which we merge to when a release is feature-complete, then do beta releases from that.

Or, we move active development from master to another branch. What we can't do is completely halt all development outside of feature branches every time we issue a beta release, until a stable release is done.

Not doing beta releases... Chances are that we'e never get anything really stable published. Basically the current situation.

Usage of pull requests for releases sounds interesting. How exactly would it work?

[bensku]

Alright. I have thought about this a bit more.

The problem is, a stable release needs to be tested, by users if possible. Otherwise we couldn't really claim that is stable. If we create such a beta release from master branch, we must not push anything unrelated to master until we manage to release the stable one.

This would effectively require tracking feature development in another branch (Njol used dev for that at some point). But if it comes to that, we can just use the master branch...

Maybe, when we want to start preparing a stable release, we merge master to another branch, for example 'freeze'. Feature development will continue in master, while bug fixes will be done in freeze, and then merged to master. So only one additional branch, instead of one additional branch per release.

The issue with this approach is that we cannot release patches for previous stable release, if we are already working on bugs of the next one in freeze. But it shouldn't be that big issue with this small project.

[bensku]

@SkriptLang/developers Opinions on my previous idea? Better ideas? Current model is not really nice, and I'd prefer not to use it for many releases after current (released today).

[Snow-Pyon]

I have thoroughly thought it and the main idea seems promising to me.

But the thing that is currently arousing me is: What would we treat as stable though? If you think about it, there are lots of things that are just not prepared to be in a "stable" release such as:

• The current storage system (the SQL support doesn't even work properly anymore and that's just a little problem about it).
• The amount of parser bugs (StackOverFlowErrors when a line is too long, Skript not being able to parse two variables in a row, random parse time slowdowns with specific words; just to mention some).
• Some rather big performance issues (adding objects to lists, the contains condition)
• Stuff that is just not working at all (event values time states).

[bensku]

Hmm... While we should talk about this more before actually doing a stable release, currently I think that

• Storage system not working is not going to fly; fix it or (more likely) disable it for the stable release, maybe with a hidden config toggle
• Amount of parser bugs visible to users without addons is generally not that significant
  • Parser limitations are sometimes quite visible, but natural language parsing is hard, no way around that
• Performance issues do not prevent putting out a stable releases, as they do not impact stability
• Time states of event values must be fixed before a stable release

I still think we should stop endless dev releases and actually go for alpha/beta releases instead. And a stable release, well, when it is ready.