Use semantic versioning

[Someone-Practice]

Issue

Currently, the releases uses "Release VV" versioning scheme, the packages in releases uses "smartdns.1.YYYY.MM.DD-[MS?].ARCH-OS-all.ipk", and the openwrt makefile uses "1.YYYY.VV".

There is no consistency and will cause issues when packaging. The GitHub release page also has "Release Release 45" as its title which looks weird.

To resolve

Use semantic versioning for all releases and packages, such as "1.45.0", "1.45.1", "1.46.0" and so on.

[pymumu]

The version number rule of smartdns in openwrt is 1.year.ver
The next version should be 1.2024.45

[PikuZheng]

The next version should be 1.2024.45

what about patch version? 1.2024.45.1?

[BKPepe]

@pymumu I think, you misunderstood OP issue.

• Looking at https://github.com/pymumu/smartdns/releases/tag/Release45, when I will download the sources, then the versioning is Release45 as OP said. It should not be Release 45 in that case, but it should be 1.2024.02.08.
  Please dont reinvent a wheel again. Just look how others are doing it.

For examples:

• https://github.com/syslog-ng/syslog-ng/releases/tag/syslog-ng-4.6.0
• https://github.com/netdata/netdata/releases/tag/v1.44.3

GAP analysis:
AS-IS: We can not use tagged releases to download it. We need to checkout Git sources.
TO-BE: Be able to use tagged releases instead of checking Git sources.

[PikuZheng]

if change the method of version number, the old version may not be able to overwrite the installation. please fully consider this.

[pymumu]

Some systems that have integrated smartdns include archlinux, dd-wrt, debian, gentoo, etc. If modify the tag rules, must consider the compatibility of these systems.

[pymumu]

Based on the current situation, I think the possible tag rules are v45, v46...

Also, whether the changes in openwrt affect software package upgrades?

[BKPepe]

Based on the current situation, I think the possible tag rules are v45, v46...

And how this follows semantic versioning? 🤔

I think everyone will appreciate if there is some consistency and you will do it properly how it should. Why OpenWrt should have special versioning than what is done in other GNU/Linux distros? Just look at https://archlinux.org/packages/extra/x86_64/smartdns/ they are are using v45, which does not follow semantic versioning.

You dont need to consider compatibility of these systems, when you will change the versioning. They will adapt to it and all GNU/Linux could have the same versioning and use tagged releases instead of checking Git sources.

[pymumu]

@felixonmars Any suggestion?

[felixonmars]

Packaging-wise we always have the flexibility to adapt to any version scheme that upstream decides on. The Arch way would be adding an "epoch" permanently (causing the future package versions to be 1:1.45.0, for example).

On the other hand, I'm not convinced that changing to a new versioning scheme when there are already two is a good idea. The v45/v46 ones are generally used here and referred to in issues, blogs, and many other places, so it may make more sense if the openwrt one were to be changed into it as well (as a bonus point, it's an upgrade anyway so no special handling is needed).

[BKPepe]

Packaging-wise we always have the flexibility to adapt to any version scheme that upstream decides on

I am thinking about this and I am like what? 🤔
You are the upstream in this case. You should decide and know what you do. No one should change your version scheme.
Why would downstream distribution do that? It makes no sense for users and as well for them because it will not match the upstream. Have you looked at my provided examples? No one, who is technical enough would not do that. syslog-ng, netdata, and many other applications know semantic versioning, and no distribution was so proactive to change their versioning to their own.

I'm not convinced that changing to a new versioning scheme when there are already two is a good idea.

So, now you do have two versioning, and you need to know what is correct and what downstream distribution like OpenWrt should use. My first opinion was to use a different version scheme and IMHO, and you are using that too in that tagged release, but other distributions should use v45 and v46.

The v45/v46

Again, I will ask. Why are you trying to reinvent the wheel or redo the wheel once it was invented? The semantic versioning or others are ready to use. Your versioning, like v45 and v46, is not good.

[pymumu]

v45, v46 are intended to maintain the continuity of version numbers.
If we use v1.45.0 instead, then the version relationship is unclear.
For Debian systems, the upgrade may fail.

@cdluminate
Any suggestion for debian?

[felixonmars]

Why would downstream distribution do that? It makes no sense for users and as well for them because it will not match the upstream.

What I was describing is the distribution-wise generic solution for situations like upstream versioning scheme change causing a new release to be "lower" in version, and it's called an "epoch". It exists because the distributions need to make versions monotonically increasing even if software upstream does not, like in this case, you are suggesting to change to semantic versioning.

It's not an invention to make users see different versions (like 1:1.45.0) than upstream, it's a compromise and a result.

https://wiki.archlinux.org/title/PKGBUILD#epoch
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_epoch_tag

[cdluminate]

v45, v46 are intended to maintain the continuity of version numbers. If we use v1.45.0 instead, then the version relationship is unclear. For Debian systems, the upgrade may fail.

@cdluminate Any suggestion for debian?

v45 > v1.45.0 so the upgrade will not work. Similar to archlinux (as what felix said), we can introduce an epoch number.

[BKPepe]

v45, v46 are intended to maintain the continuity of version numbers.

Hm, but what's wrong to use keep such consistency there like v45.0.0, v46.0.0, it looks odd, I admit, but it works.

upstream versioning scheme change causing a new release to be "lower" in version, and it's called an "epoch".

Let me copy&paste the comment from one guy from Alpine here:

---

I don't think epoch is a good idea, and even if apk gets support for it, I don't think we will allow its use in Alpine.
Also in debian you have to consult with debian-devel and get consensus before using them.

---

That's up to Debian package maintainer of smartdns, there. With epoch number, you need to be very careful and I would not do such thing for smartdns and it does not work for all distributions as said above.

it's a compromise and a result.

I disagree a lot on this one. Your decision since the beginning was wrong - double versioning. Now, you are trying to correct it somehow to unify it, which is great from you, of course. So, now you need to come up with the solution. Linux distros will handle it on their own. Most likely, because they could force their build system to downgrade it, which would not be downgrade after all.

[PikuZheng]

2024.45.0-1 （no letters）maybe better and compatible

[BKPepe]

Why would you like to have there year? 🤔

• 2024-45.0-1
• 2025-46.0-2

It does not make sense to have there year, if you are not going to reset any of those numbers. It looks weird. In my work, we do have this versioning for several systems like 43.02.3, it works, you know. :) You could easily adapt to it. No huge changes.

[felixonmars]

it's a compromise and a result.

I disagree a lot on this one. Your decision since the beginning was wrong - double versioning. Now, you are trying to correct it somehow to unify it, which is great from you, of course. So, now you need to come up with the solution. Linux distros will handle it on their own. Most likely, because they could force their build system to downgrade it, which would not be downgrade after all.

I am the Arch packager of smartdns and I'm only providing supporting information about how we are going to handle this situation to @pymumu, the author, here. The double versioning has nothing to do with me since I do not represent the smartdns project, so you are complaining to the wrong person.

upstream versioning scheme change causing a new release to be "lower" in version, and it's called an "epoch".

Let me copy&paste the comment from one guy from Alpine here:

I don't think epoch is a good idea, and even if apk gets support for it, I don't think we will allow its use in Alpine. Also in debian you have to consult with debian-devel and get consensus before using them.

This "epoch is good or not" discussion is off-topic here. Please take it elsewhere.

That's up to Debian package maintainer of smartdns, there. With epoch number, you need to be very careful and I would not do such thing for smartdns and it does not work for all distributions as said above.

@cdluminate is the Debian package maintainer of smartdns and he has already replied above.

[Someone-Practice]

Personally I believe that versioning scheme should at least be consistent.
As of now it's all over the place, even in upstream releases there are two schemes present.

Since some package managers do not like non-numeric versions, perhaps we can start with 46.0.0 in the next release and increment from there?

[PikuZheng]

Since some package managers do not like non-numeric versions

Strongly Agree. I think using numbers and . only is a good choice. To make legacy versions compatible, the first number should be large enough.

[pymumu]

Now, after the version rule changes, the downstream can handle with use the epoch number, and it seems that there is no problem in changing the version rule to v1.45.0