I think so many people are using more recent versions without any trouble, and really a number of corrections and bug fixes have been implemented. Wouldn’t it be useful in the interest of the users to release a new one?
It’s not about “update frenzy”, it’s that the changes are there and people could take advantage of them.
Why not having a 6-months release cycle? it’s reasonable to ensure that newly introduced features/fixes do not involve regressions. Also, it’s always possible, every six months, to release as stable the code which was made available one month earlier, to increase even more the tolerance to (potential) bugs introduced shortly before the release.
Strictly speaking, there are no “stable releases”, it is a “rolling release”.
So, there is no stability difference between v0.13.0-0, or v0.13.0-1 & etc.
The only difference that there can be “defined”, is between the end of the previous “cycle” v0.12.0-700 and the start of the new one v0.13.0-0. Normally, there is an intent to only merge bug fixes.
Where I personally may like the “dates” “2026.01” in the tag, simply because they should be easier to memorise than “it was fixed in v0.13.0-646-…”, which normally requires me to look through the git history to determine.
If you are talking about “release” management, that implies that someone is interested in maintaining a stable release. Which implies that someone wants to backport changes/fixes & etc.
But I’m not sure it makes any practical sense, as stated, every commit in general is as stable as any other in the tree.
Where to do so, it would require some human resources, which are scarce.
Often, it may not be possible, as some “proper” fixes imply refactoring of code.
This will multiply the amount of work and the size of the context.
Basically, right now, I can say, “Update plz, I know the state of the latest code, and we can debug it from there”. Whereas with stable tags/braches, I would be forced to also know the state of “stable” branch.
Regards,
-Timofey
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Who cares exept for commercial users I dont’t I want the latest features as soon as they hits somewones brain, cutting edge and troubleshooting is whats this tech is all about.
If you are a sissy go to Bambu bambies!
In short, it’s time consuming to tag a release. (Or, more specifically, it’s time consuming to perform the additional testing and reviewing that makes a tagged release have value.)
I’d like to tag the next release before the end of this year. I suspect a release every year or so would be something to strive for.