Procedure for determining version numbers for add-ons
Moderator: Forum Moderators
Procedure for determining version numbers for add-ons
This was just posted with the latest update to BfW.
Maybe a developer or experienced coder could post a "recommended procedure" for versioning, so there might be consistency between add-ons?
Thanks.
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.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.
Maybe a developer or experienced coder could post a "recommended procedure" for versioning, so there might be consistency between add-ons?
Thanks.
Author of:
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
Re: Procedure for determining version numbers for add-ons
The most common convention I've seen (and the one I use is):
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.
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.
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: 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
Old UMC works: 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
Re: Procedure for determining version numbers for add-ons
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.
I hope you do give a try -- if only to see how your numerous code snippets were implemented, ha ha.
Author of:
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
DIY Campaign, Confederacy of Swamp Creatures: Big Battle 1, Confederacy of Swamp Creatures: Big Battle 2, Frogfolk Delivery Service, The Pool of Ek.
Re: Procedure for determining version numbers for add-ons
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
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.
Re: Procedure for determining version numbers for add-ons
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.
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.
Re: Procedure for determining version numbers for add-ons
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.
- 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
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.
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!)
Creator of Burning Souls, The Fall of Wesnoth (abandoned) and Adventures of Knighthood (now available on BfW 1.15!)
Re: Procedure for determining version numbers for add-ons
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: Mastodon: @egallager@treehouse.systems, Steam: egallager
General mods collection, SotBEEE, AToTBWaTD, The Earth's Gut, A Little Adventure, FtF
Social media: Mastodon: @egallager@treehouse.systems, Steam: egallager
- Lord-Knightmare
- Discord Moderator
- Posts: 2358
- 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
I follow this rule specifically.egallager wrote: ↑April 22nd, 2021, 3:11 am Just linking semantic versioning here: https://semver.org/
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.
Creator of "War of Legends"
Creator of the Isle of Mists survival scenario.
Maintainer of Forward They Cried
User:Knyghtmare | My Medium
Creator of the Isle of Mists survival scenario.
Maintainer of Forward They Cried
User:Knyghtmare | My Medium
- lhybrideur
- Posts: 369
- Joined: July 9th, 2019, 1:46 pm
Re: Procedure for determining version numbers for add-ons
Can a code really be bug-free?Lord-Knightmare wrote: ↑April 22nd, 2021, 11:26 amI follow this rule specifically.egallager wrote: ↑April 22nd, 2021, 3:11 am Just linking semantic versioning here: https://semver.org/
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.
Let's say there is no obvious game-breaking bug.
- Lord-Knightmare
- Discord Moderator
- Posts: 2358
- 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
No, there will always be some bugs. What I meant was something not broken or not causing 500+ warning lines in the log file.Can a code really be bug-free?
Creator of "War of Legends"
Creator of the Isle of Mists survival scenario.
Maintainer of Forward They Cried
User:Knyghtmare | My Medium
Creator of the Isle of Mists survival scenario.
Maintainer of Forward They Cried
User:Knyghtmare | My Medium