On Wesnoth's version numbering scheme, and Wesnoth 2.0

It’s a tradition for the Battle for Wesnoth community to explain what our software version numbers mean to newcomers, since these often ask what’s the difference between the stable series, and the development series, and what happens when a new stable version is defined.

A simple answer addressing the difference between odd/even minor version numbers (i.e. Y in X.Y.Z) has usually sufficed, but now that we are producing releases for the 1.9 development series, misconceptions about the next major series (2.x) spread like the plague. I wrote clarification post a couple of months ago, on the numbering scheme — since it’s getting lost in the depths of the Users’ Forum archive, I'll replicate it here for the few anonymous people who read this.

I’m also going to explain what’s the deal with this magic “2.0” version number, although that part is going to be a lot more subjective — in other words, I’ll address that subject from my own point of view instead of the development team’s.

The version numbering system we use follows an A.B.C pattern, where A is the major version number (so far we’ve had 0 and 1), B is the branch number, and C is the revision or release number. You can also consider A and B “major” and “minor”, respectively.

Occasionally you’ll might come across a version number with a short suffix on C, such as “a” in “1.1.2a”, indicating that there was a serious game-breaking issue with the original release with the unprefixed number, which is fixed by the revised version. In these cases users of one or more platforms are encouraged to update if they had already downloaded the original broken version.

These numbers are independently increased following a decimal (base 10) pattern. Thus, 1.6.1 is followed by 1.6.2 in the same branch. 1.8.x is followed by the 1.9.x series, which is in turn followed by 1.10.x, contrary to most users’ assumptions, which may stem from the perception of these numbers as fractional steps. I’ll refer to 2.0’s specifics later below.

Even/zero series/branch numbers correspond to stable branches starting with 1.0. Odd numbers correspond to development branches. The development releases considered closer to the project’s goals for the next stable start getting labeled as “betas” and “Release Candidates” (RCs). The development series ends once we consider the potential next RC to be stable enough — that’s when the first release for the new stable branch occurs.

Most players don’t need to use a development release. Whenever they decide to use a development version, they agree to bear with any potentially show-stopping bugs they may stumble upon during gameplay, and hopefully, report it to us, which is often essential so we can fix them — either because we won’t find the bug on our own, or because we might be gathering further information and experiences on the issue.

Content compatibility is not guaranteed between development releases until the later stage. We always do our best to keep betas and RCs compatible amongst themselves — particularly so for the RCs. Individual releases in the same stable series, however, are always compatible with other versions of the same stable series (and, unofficially, RCs of the development series it stemmed from) for multiplayer and saved singleplayer games.

We are certainly not going to release a 2.0 series once 1.9.x becomes stable — so you’ll have to accept 1.10.x as a number series instead, regardless of its ugliness.

You might be wondering what’s then important enough to warrant bumping the major version digit. Different users and developers will give you different answers, but I’ll give you one of my own based on what I feel needs to be completed before planning a big celebration like that.

The GUI2 transition
Started around March 2008 following the release of Wesnoth 1.4, with Mordante’s first commit to src/gui/ in SVN trunk, the goal of this sub-project is dropping the old SDL_ttf (freetype2) based toolkit upon which the game user interface was built back in the day, now known as GUI1. The new Pango-based toolkit is supposed to address the shortcomings of our former approach: RTL and Asian language support, text formatting limitations, support for newer codepoint ranges such as those used for the Shavian alphabet, and more.
OpenGL-driven rendering of the game display
Wesnoth has become increasingly bloated with animations that may play at different times, even simultaneously. While rendering everything using software interfaces (SDL, namely) has worked pretty well for us in the past, it’s starting to show its limitations as with the current workload involved in rendering animated terrains and units at the same time, particularly in 1.9.x. There are plans to switch to OpenGL for 2D rendering at some point in the future — alink himself is currently working on experimental patches to make Wesnoth use OpenGL instead of software.
Animation consistency and quantity
Many Default era or mainline campaign units still don’t have animations (or even baseframes in the most extreme cases) on par with the current quality standards set by our Art Director. For this reason there are some inconsistencies between animations which should theoretically look similar, such as the Trapper vs. Boneshooter in melee combat, or the non-animated Nightgaunt/Spectre compared to the fully animated Shadow/Wraith.
Portraits
While the Default era is almost complete in terms of portraits, some mainline campaigns still lack portraits in the current style, which occasionally causes jarring situations in which cartoony characters talk with the more realistic generic portraits.
Campaigns
There’s one mainline faction that doesn’t have a mainline campaigns of its own yet: the Drakes. This is soon going to change, as long as ESR and Fendrin complete their work on Wings of Victory (not related to Brave Wings in any way).

• • •

As you can see, there’s still a very long way to go before Wesnoth hits the next major milestone, and most of the way is being paved since years ago. Being a volunteer-driven project, it’s hard to say when our plans will be finally realized, so the good old Wesnothian mantra applies: It Is Ready When It Is Ready.

Software, Wesnoth