Proposal: abandon the even-odd versioning system #416

New Issue

2026-10-05T04:19:27+02:00

adam commented

2026-10-05 04:19:27 +02:00

ZNC has a special even-odd versioning system, where odd numbers are so called development versions, and even numbers are stable releases. This versioning system worked with version numbers like 0.096, 0.098, 0.202, 0.204, 0.206 because people didn't have expectations for such running beta-like version numbers. In other words, the version numbers didn't have a strong significance - they looked more like version control revision numbers.

Things have changed when ZNC switched to the MAJOR.MINOR versioning system. Starting from version 1.0, people have had certain expectations. Based on the version number, it looks like ZNC is following the industry standards. People get confused when they find out that this and that version never was/will be released. This confusion caused by ZNC's even-odd system keeps coming up on #znc, again and again.

The value added by the even-odd system is questionable. It's a source of confusion, and wastes good minor version numbers for no apparent reason. Any unreleased version should be considered a "development version". With ZNC it should be clear anyway, because if ZNC is built from Git, the version number has a git-tag together with a SHA1. Nightlies have a nightly-tag together with a date. Why is that not clear enough? Are you afraid that people will create their own releases with make-tarball.sh and pretend that they have an official version?

PS. I'd imagine that the even-odd system gets even more confusing with the upcoming MAJOR.MINOR.PATCH versioning system...

ZNC has a special even-odd versioning system, where odd numbers are so called development versions, and even numbers are stable releases. This versioning system worked with version numbers like `0.096, 0.098, 0.202, 0.204, 0.206` because people didn't have expectations for such running _beta-like_ version numbers. In other words, the version numbers didn't have a strong significance - they looked more like version control revision numbers. Things have changed when ZNC switched to the `MAJOR.MINOR` versioning system. Starting from version `1.0`, people have had certain expectations. Based on the version number, it looks like ZNC is following the industry standards. People get confused when they find out that this and that version never was/will be released. This confusion caused by ZNC's even-odd system keeps coming up on #znc, again and again. The value added by the even-odd system is questionable. It's a source of confusion, and wastes good minor version numbers for no apparent reason. Any unreleased version should be considered a "development version". With ZNC it should be clear anyway, because if ZNC is built from Git, the version number has a git-tag together with a SHA1. Nightlies have a nightly-tag together with a date. Why is that not clear enough? Are you afraid that people will create their own releases with `make-tarball.sh` and pretend that they have an official version? PS. I'd imagine that the even-odd system gets even more confusing with the upcoming `MAJOR.MINOR.PATCH` versioning system...

adam closed this issue

2026-10-05 04:19:27 +02:00

adam commented

2026-10-05 04:19:28 +02:00

+1 and to align to the semantic versioning standard.

+1 and to align to the [semantic versioning](http://semver.org) standard.

adam commented

2026-10-05 04:19:29 +02:00

Amount of numbers is big, wasting them doesn't make much difference :-) We even wasted every number between 0.207 and 1.0, also numbers like 1.01384687230856, √2, and 1+2i... :-)

When ZNC is built from git, it adds SHA1, yeah. It wasn't always the case. Now it adds them, so I agree.

One source of confusion which I foresee, is when someone says that they have 1.3. Which exact 1.3 they meant? Released 1.3, or one of git/nightly versions?
Sometimes people don't realize that the whole version number is needed, and instead of copypasting the whole version string they just type what they think is version number.
Right now when someone says that they have 1.3, it's clearly visible that something is missing, because there is no (and will be no) released 1.3

Amount of numbers is big, wasting them doesn't make much difference :-) We even wasted every number between `0.207` and `1.0`, also numbers like `1.01384687230856`, `√2`, and `1+2i`... :-) When ZNC is built from git, it adds SHA1, yeah. It wasn't always the case. Now it adds them, so I agree. One source of confusion which I foresee, is when someone says that they have `1.3`. Which exact `1.3` they meant? Released `1.3`, or one of git/nightly versions? Sometimes people don't realize that the whole version number is needed, and instead of copypasting the whole version string they just type what they think is version number. Right now when someone says that they have `1.3`, it's clearly visible that something is missing, because there is no (and will be no) released `1.3`

adam commented

2026-10-05 04:19:29 +02:00

Amount of numbers is big, wasting them doesn't make much difference :-) We even wasted every number between 0.207 and 1.0, also numbers like 1.01384687230856, √2, and 1+2i... :-)

As said, minor and patch level version numbers tend to lose their significance the larger they get. By skipping numbers you reach two digits much faster. Please consider releasing more often and take the unused numbers in use instead.

One source of confusion which I foresee, is when someone says that they have 1.3.

1.3 was already skipped so let's talk about 1.5 instead to avoid confusion.

Which exact 1.3 they meant? Released 1.3, or one of git/nightly versions?

Now that you have M.N.P, 1.5 means the 1.5.x series. Talking about 1.5 still makes sense, because any 1.5.x release is feature-wise equal. That's one of the reasons why bug fix releases must not contain anything but stabilizing bug fixes. They must not add/remove any features, they must not change the config. There's a whole lot of things to discuss that applies to the whole 1.5 series.

Sometimes people don't realize that the whole version number is needed, and instead of copypasting the whole version string they just type what they think is version number.

This happens no matter how you format the version. Even if you would make it a single running version number, human beings (excluding us software engineers) would then start talking about "thirty-something".

Right now when someone says that they have 1.3, it's clearly visible that something is missing, because there is no (and will be no) released 1.3

The way I see is that ZNC is trying to avoid confusion by pushing it to the customers. The problem is that the confusion faced by ZNC customers is effectively multiplied, because ZNC is the one not playing by the rules. :P

> Amount of numbers is big, wasting them doesn't make much difference :-) We even wasted every number between 0.207 and 1.0, also numbers like 1.01384687230856, √2, and 1+2i... :-) As said, minor and patch level version numbers tend to lose their significance the larger they get. By skipping numbers you reach two digits much faster. Please consider releasing more often and take the unused numbers in use instead. > One source of confusion which I foresee, is when someone says that they have 1.3. 1.3 was already skipped so let's talk about 1.5 instead to avoid confusion. > Which exact 1.3 they meant? Released 1.3, or one of git/nightly versions? Now that you have M.N.P, 1.5 means the 1.5.x series. Talking about 1.5 still makes sense, because any 1.5.x release is feature-wise equal. That's one of the reasons why bug fix releases must not contain anything but stabilizing bug fixes. They must not add/remove any features, they must not change the config. There's a whole lot of things to discuss that applies to the whole 1.5 series. > Sometimes people don't realize that the whole version number is needed, and instead of copypasting the whole version string they just type what they think is version number. This happens no matter how you format the version. Even if you would make it a single running version number, human beings (excluding us software engineers) would then start talking about "thirty-something". > Right now when someone says that they have 1.3, it's clearly visible that something is missing, because there is no (and will be no) released 1.3 The way I see is that ZNC is trying to avoid confusion by pushing it to the customers. The problem is that the confusion faced by ZNC customers is effectively multiplied, because ZNC is the one not playing by the rules. :P

adam commented

2026-10-05 04:19:30 +02:00

1.3 was already skipped so let's talk about 1.5 instead to avoid confusion.

It could be 15.16, I tried to use some abstract number to avoid current version numbers to avoid confusion of those who will read this log in future :)

Talking about 1.5 still makes sense, because any 1.5.x release is feature-wise equal.

No. You're not going to make the whole multifeature new release in a single git commit, right?
Or every new feature commit need to bump version number? Then numbers will waste even faster.
If 2 new features are added, there is some version where only one of them is already added. And that version has the same version number.

bug fix releases must not contain anything but stabilizing bug fixes.

I agree. But this has nothing to do with development (non-tagged) versions. If there is new bugfix release which fixes 2 bugs, they are fixed not in the same commit, I guess. So we have 15.16.17 already released, and there are several different 15.16.18, one of which contains only 1 bugfix, and another 15.16.18 contains both bugfixes.

The way I see is that ZNC is trying to avoid confusion by pushing it to the customers.

I just don't see how the proposed way is less confusing.

> 1.3 was already skipped so let's talk about 1.5 instead to avoid confusion. It could be `15.16`, I tried to use some abstract number to avoid current version numbers to avoid confusion of those who will read this log in future :) > Talking about 1.5 still makes sense, because any 1.5.x release is feature-wise equal. No. You're not going to make the whole multifeature new release in a single git commit, right? Or every new feature commit need to bump version number? Then numbers will waste even faster. If 2 new features are added, there is some version where only one of them is already added. And that version has the same version number. > bug fix releases must not contain anything but stabilizing bug fixes. I agree. But this has nothing to do with development (non-tagged) versions. If there is new bugfix release which fixes 2 bugs, they are fixed not in the same commit, I guess. So we have `15.16.17` already released, and there are several different `15.16.18`, one of which contains only 1 bugfix, and another `15.16.18` contains both bugfixes. > The way I see is that ZNC is trying to avoid confusion by pushing it to the customers. I just don't see how the proposed way is less confusing.

adam commented

2026-10-05 04:19:31 +02:00

Talking about 1.5 still makes sense, because any 1.5.x release is feature-wise equal.

No. You're not going to make the whole multifeature new release in a single git commit, right?
Or every new feature commit need to bump version number? Then numbers will waste even faster.
If 2 new features are added, there is some version where only one of them is already added. And that version has the same version number.

Any 1.5.x release. Anyone using a non-released version has either a -git- or -nightly- a tag in the version.

bug fix releases must not contain anything but stabilizing bug fixes.

I agree. But this has nothing to do with development (non-tagged) versions. If there is new bugfix release which fixes 2 bugs, they are fixed not in the same commit, I guess. So we have 15.16.17 already released, and there are several different 15.16.18, one of which contains only 1 bugfix, and another 15.16.18 contains both bugfixes.

Same thing here. Unreleased versions are -git/nightly- tagged.

The way I see is that ZNC is trying to avoid confusion by pushing it to the customers.

I just don't see how the proposed way is less confusing.

The rest of the software industry is happy with the proposed way. :P Following a widely-accepted standard would easily avoid the confusion that is seen on the channel amongst new users on a weekly basis.

> > Talking about 1.5 still makes sense, because any 1.5.x release is feature-wise equal. > > No. You're not going to make the whole multifeature new release in a single git commit, right? > Or every new feature commit need to bump version number? Then numbers will waste even faster. > If 2 new features are added, there is some version where only one of them is already added. And that version has the same version number. Any 1.5.x **release**. Anyone using a non-released version has either a -git- or -nightly- a tag in the version. > > bug fix releases must not contain anything but stabilizing bug fixes. > > I agree. But this has nothing to do with development (non-tagged) versions. If there is new bugfix release which fixes 2 bugs, they are fixed not in the same commit, I guess. So we have 15.16.17 already released, and there are several different 15.16.18, one of which contains only 1 bugfix, and another 15.16.18 contains both bugfixes. Same thing here. Unreleased versions are -git/nightly- tagged. > > The way I see is that ZNC is trying to avoid confusion by pushing it to the customers. > > I just don't see how the proposed way is less confusing. The rest of the software industry is happy with the proposed way. :P Following a widely-accepted standard would easily avoid the confusion that is seen on the channel amongst new users on a weekly basis.

adam commented

2026-10-05 04:19:31 +02:00

Nginx has a different versioning system again. Odds are so called "Development" (mainline) releases, which add new features, and evens are so called "Stable" releases, which only update for bug and security fixes. So really, what is this all about!?

Nginx has a different versioning system again. Odds are so called "Development" (mainline) releases, which add new features, and evens are so called "Stable" releases, which only update for bug and security fixes. So really, what is this all about!?

adam commented

2026-10-05 04:19:32 +02:00

The thing about nginx mainline is that they actually do release them with proper minor version bump, while znc recycles the same version number for the whole development period.

Personally I'd like to see versioning without gaps too. As right now saying that you use 1.5 version doesn't mean anything, you always has to referrer to the git hash.

The thing about nginx mainline is that they actually do release them with proper minor version bump, while znc recycles the same version number for the whole development period. Personally I'd like to see versioning without gaps too. As right now saying that you use 1.5 version doesn't mean anything, you always has to referrer to the git hash.

adam commented

2026-10-05 04:19:33 +02:00

How about just using date? YYYY.MM.DD would also easily show users when their ZNC was released and could make it easier to notice when to update.

There is a lot of different views on it. I personally like this article supporting date as versionnumber.

How about just using date? YYYY.MM.DD would also easily show users when their ZNC was released and could make it easier to notice when to update. There is a lot of [different views on it](https://www.google.fi/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=date%20as%20version). I personally like [this article supporting date as versionnumber](http://blog.codinghorror.com/whats-in-a-version-number-anyway/).

adam commented

2026-10-05 04:19:33 +02:00

@Mkaysi Is 2014.08.05 new enough? And what if a security bug was fixed a day later?
That article is biased towards .NET and "products".
Semver is biased towards stable API of libraries. (disclaimer: I don't say if it's good or bad)

Also lots of people just do apt-get install znc and stick with whatever ancient version gets installed, without even looking at its version name (with year or without)

@Mkaysi Is 2014.08.05 new enough? And what if a security bug was fixed a day later? That article is biased towards .NET and "products". Semver is biased towards stable API of libraries. (disclaimer: I don't say if it's good or bad) Also lots of people just do `apt-get install znc` and stick with whatever ancient version gets installed, without even looking at its version name (with year or without)

adam commented

2026-10-05 04:19:34 +02:00

@Mkaysi Is 2014.08.05 new enough? And what if a security bug was fixed a day later?

Topic of #znc would probably mention the latest version and if there was security bug fixed day later.

> @Mkaysi Is 2014.08.05 new enough? And what if a security bug was fixed a day later? Topic of #znc would probably mention the latest version and if there was security bug fixed day later.

adam commented

2026-10-05 04:19:35 +02:00

Let's not rely on every user of ZNC being on #znc... (and even reading the topic)

Let's not rely on every user of ZNC being on #znc... (and even reading the topic)

adam commented

2026-10-05 04:19:35 +02:00

Version polling!!!

Version polling!!!

adam commented

2026-10-05 04:19:36 +02:00

+1

+1

adam commented

2026-10-05 04:19:37 +02:00

How about the weechat -style versioning? The more I think about it, the more I like it.

1.7.0 // a released & tagged version
1.7-git-123-abcdefg // a dev build from git
1.7-nightly-2015-02-19-abcdefg // a nightly build
(1.7 // a "self-made" tarball build if not using a released & tagged revision)

=> Releases have proper semver, anything unofficial has a two level version number to clearly indicate that it's not any specific release.

How about the weechat -style versioning? The more I think about it, the more I like it. - 1.7.0 // a released & tagged version - 1.7-git-123-abcdefg // a dev build from git - 1.7-nightly-2015-02-19-abcdefg // a nightly build - (1.7 // a "self-made" tarball build if not using a released & tagged revision) => Releases have proper semver, anything unofficial has a two level version number to clearly indicate that it's not any specific release.

adam commented

2026-10-05 04:19:37 +02:00