Procedure for determining version numbers for add-ons

Get help with compiling or installing the game, and discuss announcements of new official releases.

Moderator: Forum Moderators

Post Reply
User avatar
Helmet
Posts: 331
Joined: December 19th, 2006, 5:28 pm
Location: Florida, USA

Procedure for determining version numbers for add-ons

Post by Helmet »

This was just posted with the latest update to BfW.
Add-on version check when uploading
  • Additionally, in an effort to help avoid potential issues, when uploading an add-on you've created to the official add-ons server you must now always increment the add-on's version. Attempting to upload an existing add-on with the same version or a lower version will be rejected.
What are the "best practices" for versioning? My first completed campaign will be on the server in the near future, and I'd like to employ a good procedure.

Maybe a developer or experienced coder could post a "recommended procedure" for versioning, so there might be consistency between add-ons?

Thanks.
User avatar
WhiteWolf
Forum Moderator
Posts: 749
Joined: September 22nd, 2009, 7:48 pm
Location: Hungary

Re: Procedure for determining version numbers for add-ons

Post by WhiteWolf »

The most common convention I've seen (and the one I use is):
Major.Minor.Patch
Here are the meanings that I attach to it:
A 0 major means work in progress or incomplete. 1.x.y is the initial full release, generally speaking.
By default, an odd minor means development version, an even minor means stable version. Wesnoth itself does this (currently 1.14.x being stable and 1.15.x being development).
Add-ons maybe don't have to follow this that strictly, so you can increment your minor one by one. I certainly don't follow it consequently, for example my add-on is at 1.3.7 but hasn't seen an update for at least half a year. But you could choose to stick strictly to the convention, and number it odd if you add patches and updates often, and number it with an even number if maintenance is on a break. This is up to you.
Patch version is what you increment with small patches.

So you could start out with 1.0.0, and just increment the patch each time you fix something or make small updates. These should be generally compatible with saved games, so a saved game made in 1.0.5 should be able to load and function in 1.0.6 without problems.
If you add new content or make a save-game compatibility breaking change, definitely increase at least the minor.
If you add huge new contents or make things that you feel is worthy of the "2.0 is here!" big announcement, then increment the major version.
If you don't ever plan to do that big changes, and the major would stay "1" forever, you can get rid of it altogether, and just use two number version numbering, "Minor.Patch".

Some people add even letters at the end like 1.2.3c. I would only do that if it's the same contentwise, but I had to update because of something. Like if I mistyped the title image of the pbl file for the add-ons server for version 1.2.3, and I had to reupload because of that but my content got no changes, then I'd do that by labeling it 1.2.3a. Which is the same as 1.2.3, just a reupload. But this is just my idea.

So these are just my thoughts and my convention, it has advantages, but feel free to interpret your own numbering :)
I'm interested how your campaign will turn out - I may give it a go if I find the free time, once you publish it.

EDIT:
Btw, there's a set of useful examples here.
Author of the Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Standalone works: The Ravagers - now for 1.14, with new bugs!
User avatar
Helmet
Posts: 331
Joined: December 19th, 2006, 5:28 pm
Location: Florida, USA

Re: Procedure for determining version numbers for add-ons

Post by Helmet »

WhiteWolf wrote: December 20th, 2020, 3:45 pm The most common convention I've seen (and the one I use is):
Major.Minor.Patch...
Thanks, WhiteWolf, that was extremely helpful. I might start with 0.8, anticipating a few mistakes that were overlooked, then wait a little while, correct the mistakes, and upload 1.0.
WhiteWolf wrote: December 20th, 2020, 3:45 pm I'm interested how your campaign will turn out - I may give it a go if I find the free time, once you publish it.
I hope you do give a try -- if only to see how your numerous code snippets were implemented, ha ha. ^_^
User avatar
Elven
Posts: 165
Joined: February 3rd, 2008, 12:02 am
Location: Slovakia
Contact:

Re: Procedure for determining version numbers for add-ons

Post by Elven »

Example:

1.1.1 - another bugfix. Newest version
1.1 - new scenarios, abilities...
1.0.1 - fixed minor bug
1.0 - completed campaign, hurrah!
0.3 - added new scenario
0.2.2 - fixed minor bug
0.2.1 - fixed minor bug
0.2 - second version
0.1 - first version
Creator of Greenie knižnica and Greenie Linux and Wesnoth unofficial LiveCD; Slovak/Czech translator and creator of many campaigns. Everything is here on one place.
shevegen
Posts: 355
Joined: June 3rd, 2004, 4:35 pm

Re: Procedure for determining version numbers for add-ons

Post by shevegen »

IMO the scheme is most important between 0.x, say 0.9, before 1.0. When I read
1.0 I would assume that most of how it was assumed to be designed works. With,
say 0.9 being closer to that goal than, say, 0.1.

I don't rely on anything as strongly as Elven would use though. To me it's mostly
just a rough estimate. There are campaigns that aren't great even at 1.0 and
then there are some that are never able to get to 1.0 before being abandoned,
but they are really much better than the other campaign ... so it's quite arbitrary
to an extent.
User avatar
Elven
Posts: 165
Joined: February 3rd, 2008, 12:02 am
Location: Slovakia
Contact:

Re: Procedure for determining version numbers for add-ons

Post by Elven »

more choices... but i believe it is perfect when UMC creator also have a changelog file...
Creator of Greenie knižnica and Greenie Linux and Wesnoth unofficial LiveCD; Slovak/Czech translator and creator of many campaigns. Everything is here on one place.
User avatar
Pewskeepski
Posts: 378
Joined: November 17th, 2010, 6:24 pm
Location: An icy dungeon beneath Antarctica

Re: Procedure for determining version numbers for add-ons

Post by Pewskeepski »

Also, (in light of using the above methods) if you have something like this:

1.1.9

And you make another patch, something small like a bug-fix, the next would be:

1.1.10, 1.1.11 and so on...

Instead of:

1.2.0.
"Everything is better with penguins."
Creator of Burning Souls, The Fall of Wesnoth (abandoned) and Adventures of Knighthood (now available on BfW 1.15!)
User avatar
egallager
Posts: 162
Joined: November 19th, 2020, 7:27 pm
Location: Concord, New Hampshire
Contact:

Re: Procedure for determining version numbers for add-ons

Post by egallager »

Just linking semantic versioning here: https://semver.org/
Wesnoth-related GitHub repos:
General mods collection, SotBEEE, AToTBWaTD, The Earth's Gut, A Little Adventure, FtF
Social media: Twitter: @cooljeanius, Steam: egallager
User avatar
Lord-Knightmare
Discord Moderator
Posts: 1560
Joined: May 24th, 2010, 5:26 pm
Location: Somewhere in the depths of Irdya, gathering my army to eventually destroy the known world.
Contact:

Re: Procedure for determining version numbers for add-ons

Post by Lord-Knightmare »

egallager wrote: April 22nd, 2021, 3:11 am Just linking semantic versioning here: https://semver.org/
I follow this rule specifically.

Also, some other notes:
If you're add-on is fully complete and bug-free, only then must the major number be 1 or higher.
User avatar
lhybrideur
Posts: 206
Joined: July 9th, 2019, 1:46 pm

Re: Procedure for determining version numbers for add-ons

Post by lhybrideur »

Lord-Knightmare wrote: April 22nd, 2021, 11:26 am
egallager wrote: April 22nd, 2021, 3:11 am Just linking semantic versioning here: https://semver.org/
I follow this rule specifically.

Also, some other notes:
If you're add-on is fully complete and bug-free, only then must the major number be 1 or higher.
Can a code really be bug-free?
Let's say there is no obvious game-breaking bug.
User avatar
Lord-Knightmare
Discord Moderator
Posts: 1560
Joined: May 24th, 2010, 5:26 pm
Location: Somewhere in the depths of Irdya, gathering my army to eventually destroy the known world.
Contact:

Re: Procedure for determining version numbers for add-ons

Post by Lord-Knightmare »

Can a code really be bug-free?
No, there will always be some bugs. What I meant was something not broken or not causing 500+ warning lines in the log file.
Post Reply