Semantic Versioning compliance proposal

Discussion among members of the development team.

Moderators: Forum Moderators, Developers

Post Reply
User avatar
loonycyborg
Windows Packager
Posts: 273
Joined: April 1st, 2008, 4:45 pm
Location: Russia/Moscow

Semantic Versioning compliance proposal

Post by loonycyborg » May 23rd, 2018, 12:48 pm

Currently wesnoth's versioning scheme isn't compliant to semver spec. While for stable versions it more or less fits, dev releases work totally not in semver way. We also lack a way to signal forward compatible(that is not breaking existing UMC) feature additions in the stable branch.

Here's the proposal:
1. we drop leading major vestigial "1.". What would be otherwise version 1.15.0 would be 15.0.0 under new scheme.
2. we drop even/odd signalling scheme for dev vs stable. It's not compliant with semver. In dev releases there aren't any guarantees on forward/backward compatibility between releases whatsoever so minor/patch versions don't have the meaning mandated by the spec. Next stable major release would be 15.0.0 under new scheme.
3. dev releases would be versioned in the way suggested in semver spec, dev releases based on master branch will be $NEXT_MAJOR_RELEASE.0.0-alpha.1, $NEXT_MAJOR_RELEASE.0.0-alpha.2 etc. For example next dev release would be 15.0.0-alpha.1 under new scheme
4. release candidates - releases based on newly forked stable branch in preparation to new major stable proper. They will be versioned with rc suffix instead: $NEXT_MAJOR_RELEASE.0.0-rc.1, $NEXT_MAJOR_RELEASE.0.0-rc.2. Next rc would be 15.0.0-rc.1 under new scheme.
5. in stable branches we will have two version components to play with. Minor version will be used to signal forward compatible feature additions or deprecation of features in WML. Patch version will be incremented to signal bugfix releases. Under new scheme 15.x bugfix releases will be 15.0.1, 15.0.2. Forward compatible WML tag additions or WML tag deprecations would require minor to be incremented: 15.1.0 . Bugfixes after it: 15.1.1, 15.1.2 ...

Also note that current policy of allowing only bugfixes in stable branch probably forestalls any increment of minor version. If we change our workflow to allow greater changes to stable branches(which I think vultraz and dave wanted) then minor version will actually come into play. Until then it can remain always "0".
"meh." - zookeeper

gfgtdf
Developer
Posts: 1091
Joined: February 10th, 2013, 2:25 pm

Re: Semantic Versioning compliance proposal

Post by gfgtdf » May 23rd, 2018, 2:27 pm

i am not opposed to it, but i don't think that "It's not compliant with semver" alone is a good reason to change something.

also if we should add wml features to stable branches we should add some api (like in _server.pbl) where addons can specify their minimum required wesnoth version.

lastly i want to make clear that changes that will prevent wensoth from running on some pcs in (particular requireing ogl like what is currently worked on on master), can not go in without increasing major version number.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.

User avatar
loonycyborg
Windows Packager
Posts: 273
Joined: April 1st, 2008, 4:45 pm
Location: Russia/Moscow

Re: Semantic Versioning compliance proposal

Post by loonycyborg » May 23rd, 2018, 4:56 pm

Of course, such possibly destabilizing changes like opengl require major version increment too, even if they don't change external api.
"meh." - zookeeper

Soliton
Site Administrator
Posts: 1539
Joined: April 5th, 2005, 3:25 pm
Location: #wesnoth-mp

Re: Semantic Versioning compliance proposal

Post by Soliton » May 29th, 2018, 8:49 am

One thing to be aware of when changing the version scheme is that there is code in wesnoth and auxiliary scripts that is based on the current version scheme.
"If gameplay requires it, they can be made to live on Venus." -- scott

Post Reply