Traditional versioning like 7.0.0 or 8.0.0 often forces us to bundle features into big releases, delaying updates that could be ready much sooner.
That wait slows things down because features end up sitting in development until the next major version instead of reaching users when they’re ready.
With a date-based versioning system like 2025.02.25, we could push updates as soon as they’re finished, leading to faster feedback and continuous improvements.
@Jamie, @Joe—what are your thoughts on shifting to a continuous rollout model? We could use 2025.02 for standard releases and 2025.02.25 for bug fixes.
Many successful projects follow this model—Kali and Arch Linux, for example, use date-based versions to keep updates rolling out without artificial and most times damaging delays.
This approach could also reduce support costs by avoiding the overhead of maintaining large, infrequent version jumps.
The main challenge might be phasing out old features without breaking things, but that’s manageable. A simple solution would be keeping separate repos for any releases with breaking changes, the same way we do now—so it doesn’t seem like a real problem.
And, from a marketing perspective, date-based versions also signal active development. Major versions can sit unchanged for years—Webmin version 1 stuck around for nearly two decades, and Webmin 2 has already been around for years.
A date-based system makes it clear the product is constantly evolving.
There is nothing about the version format that makes releases slow.
I don’t see any reason to change the version format. We’re barely even on semantic versions, let’s just get everything versioned with semantic versions, and not make more work for no reason.
Most everyone understands semantic versions and what it means when a major version changes (in terms of compatibility promises, etc.).
But first and foremost, I’d like to have a discussion about the pros and cons of switching to date-based versioning, rather than just dismissing it with a simple “no reason to change version format”.
I outlined a few points in my initial post, and I think it would be valuable to have an open discussion. Who knows—we might even come up with something better than what we’ve been using for the past two decades.
That’s the point.
As the Greeks used to say, truth is born in the clash of opposing ideas.
We haven’t been using semantic versioning for the past two decades. I started using it, mostly, a few years ago for Virtualmin packages I maintain, but Jamie only recently agreed to switch Webmin/Usermin to semantic versions at some point (but hasn’t yet). I don’t think all of our Virtualmin software is even on semantic versions yet.
The format of versions has nothing to do with how large our version changes are.
You’re the one who has always insisted major version changes also include huge changes!
The main reason is that moving from version 7 to 8 is a big jump—that’s exactly what semantic versioning is about, it’s not just me saying it. A major version change signifies a significant release per se.
With a date-based versioning system like 2025.02, 2025.02.25, and 2025.12, we eliminate the concept of major releases altogether. Instead of waiting for a big jump, updates roll out continuously, keeping things moving forward without artificial delays.
It’s not, though. Semantic versions say a major version is when there is some break in backward compatibility. Removing support for old stuff, changing how things are done, etc. We absolutely do that when we do a new major version. 6 to 7 had several breaking changes!
And our planned 8 will have several breaking changes from 7. They are minor, they generally won’t effect people upgrading in-place, but it’s a change that warrants a major version bump.
What artificial delays? There is nothing in the version that stops us from rolling more frequent smaller updates. These are two different conversations. I’m willing to have either conversation, but I’m not willing to combine them into one. Date-based versions are not related to release speed/frequency/size in any way.
Well, not necessarily. Date-based versioning naturally encourages more frequent updates, whereas traditional versioning often bundles features into major releases. I think, this happens because major version bumps have historically been seen as significant milestones.
On the other hand, date-based versions reinforce a rolling-release mindset. For example, distributions like Kali and Arch use this approach precisely because they don’t rely on traditional major releases. Instead of debating whether a change should wait for “version 8,” updates are pushed continuously.
And, as mentioned earlier in the chat, date-based versions also improve user clarity. A version like 2025.02.25 immediately tells users how fresh it is. Compare that to 7.0.4—without checking a changelog, there’s no easy way to tell if that’s a recent update or an outdated version from years ago.
Yes, when I try to steel man this argument, the one positive I can come up with is that users who like to run old versions will see not only that they are running an old version, they will see how old that version is. That’s a positive.
It still feels like this has everything to do with it—this is exactly what semantic versioning is about. Everyone expects a jump from 7 to 8 to signal a major change, and that expectation forces us (devs) to accumulate features instead of releasing them as soon as they’re ready.
What if we decided to release a major version tomorrow? Would it even include that many major changes? Not unless we had intentionally held back features to make it feel substantial. But since we’ve been rolling out improvements in dot releases, there wouldn’t be much left to justify a major jump.
This is exactly where the slowdown happens—we either delay features to make a major release feel “big” (which slows development) or we push updates continuously, making major versions feel less significant.
For new users:
Date based does have the advantage of folk knowing when a release was made, but the disadvantage of making it appear to be stale and not relevant. What are folk going to think when the date indicates that it is OLDER than the EOL of the chosen OS? (eg Webmin 2004.x.x instead of Webmin 1.x.x)
For existing users:
However, there is definitely a problem with expectation. How many times are questions asked “When will the next release of *min be available? What will it contain? Will it contain ‘xyz’?” date based releases help to indicate progress and therefore manage expectations better.
I don’t see why a similar system to Ubuntu is used i.e year.month.subversion and perhaps as Ubuntu does release every six months (not there is no need for LTS versions).Given that a newer full version is at maximum six months away, this may give the devs enough time to add new features and test via the sub versions. This applies to webmin, the sub versions could updates to the webmin modules, but I guess it’s not that simple with complexity of webmin & it’s modules
I have a very strong aversion to inventing our own nonsense. There are enough new things and conventions in our products, we shouldn’t be going out of our way to invent new ones. NIH (not invented here) syndrome is something to be avoided, not sought out.
A gazillion projects use semantic versions. A significantly smaller (but still sizeable) number use dates. I’m unaware of any major project using a major.minor.date for releases (though that is very common for daily snapshot releases from a development branch in revision control).
Also, I want to point out that we’re not in unexplored territory. Version naming is not a problem unique to us, we should not discuss it as though we’re in a green field. Millions of people have had this conversation for decades.
The case for Semantic Versions (semver) is made pretty well by the website: https://semver.org/
Anyone making a case for something else ought to at least be familiar with the case for semver. I am inclined to disregard arguments that aren’t based in all the prior discussion and thought that’s gone into the problem over the past several decades.
My position is almost always that we should do what the vast majority of others are doing, unless we have a damned good reason to do something different. I also don’t want to see unrelated things, like pace of development or size of releases, be used as arguments for any of this…the pace of development has nothing to do with what the versions are named, and is entirely a function of how much time/motivation we have for development.
Semantic versioning is what the vast majority of people are doing. If we were to opt for something else, it needs to be pretty compelling.
Seeing an issue discussed, then fixed, but not rolled out for months is - to me at least - very frustrating.
I don’t really care how you name it, and I don’t see how naming systems contribute to delays in releases.
If you fix something, do a release.
If you add something new, do a release.
The speed that you guys work on programming absolutely amazes me, you probably could have done 4 projects in the time taken for this discussion.
Yeah, I think the time to change all of our systems, repos, etc. is reason enough to not change, barring some incredibly good reason. I’ve got a full-time job, and a bunch of other things that are taking my time, I just don’t want to waste it on unnecessary busy work like renaming everything.
For me, stick with current major.minor.patch as @joe points out, the naming convention will not change frequency of releases and certainly would not increase them.
