Comments (20)
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.
from smartdns.
The version number rule of smartdns in openwrt is 1.year.ver
The next version should be 1.2024.45
from smartdns.
The next version should be 1.2024.45
what about patch version? 1.2024.45.1?
from smartdns.
@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.
from smartdns.
if change the method of version number, the old version may not be able to overwrite the installation. please fully consider this.
from smartdns.
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.
from smartdns.
Based on the current situation, I think the possible tag rules are v45, v46...
Also, whether the changes in openwrt affect software package upgrades?
from smartdns.
@felixonmars Any suggestion?
from smartdns.
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).
from smartdns.
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.
from smartdns.
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?
from smartdns.
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
from smartdns.
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.
from smartdns.
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.
from smartdns.
2024.45.0-1 (no letters)maybe better and compatible
from smartdns.
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.
from smartdns.
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.
from smartdns.
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?
from smartdns.
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.
from smartdns.
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
from smartdns.
Related Issues (20)
- domain-rules的group参数问题 HOT 5
- speed-check-mode使用问题 HOT 34
- CNAME doesn't follow domain-rules HOT 4
- nft 添加 ipset 错误 HOT 5
- 网赌被黑了不给提款怎么办?解决微:lyh20085150 HOT 2
- 软路由运行4天后 Smartdns卡死崩溃 HOT 5
- 配置文件支持相对路径 HOT 3
- 设置成非53端口不能生效 HOT 1
- 223.5.5.5/dns-query支持h3吗 在我这里测试一直是h2 运营商dns可以h3 HOT 2
- 切换WLAN导致DNS查询失败
- 关于指定域名集合到特定一个ip解析的问题 HOT 3
- nftset.h 封装求助 HOT 18
- 文件权限被改变 HOT 7
- ttl 的默认值不正常 HOT 16
- 测试发现强解析存在bug HOT 3
- 无法获取新域名的 HOT 17
- 【正则匹配】域名规则有没有可能支持正则配置?
- doh支持使用特定token限制访问
- 用户日志能否支持功能调用IP识别运营商接口nali
- 定义了组名的服务器没有从默认组中排除 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from smartdns.