Date-Based Releases: Faster Updates, Better Results

[Stegan]

Cannot we just have the release date dropped into the code in a “CHANGELOG/LICENSE” or some other file that can be easily found and displayed during install/whenever?

and keep the semver system - route of least effort and best use of resources

[tpnsolutions]

Hey,

My two cents…

I agree with @Joe on the topic of going all-in “semver” model. As I understand it, semver works whereby…

MAJOR version when you make incompatible API changes

MINOR version when you add functionality in a backward compatible manner

PATCH version when you make backward compatible bug fixes

New features can be introduced at both “MAJOR” and “MINOR” release levels technically, just as long as MINOR upgrades don’t cause incompatibility.

MAJOR upgrades usually happen to do stuff like code refactoring, when the programming language you’re using is upgraded by a major release and requires re-coding (like python2 to python3) and can often signify a large bunch of new features or overall improvements.

However, MAJOR releases don’t necessarily have to focus on new features, or noticable changes.

So if @Ilia and the team want to release new features more often, they could be released in MINOR releases, then refactored later during a MAJOR release perhaps to improve performance or overall functionality.

PATCHES exist throughout the lifecycle of a MAJOR/MINOR release in order to keep bugs fixed, and vulnerabilities patched.

Overall, while I personally use “date-based” versioning for my own projects (for a completely different reason), “semver” is the more common straight forward versioning most are acustom to, and works well for quite a few projects.

Again, just my opinion on the matter. Not that some good points haven’t been brought up on either front for that matter.

[Ilia]

@tpnsolutions

So if @Ilia and the team want to release new features more often, they could be released in MINOR releases, then refactored later during a MAJOR release perhaps to improve performance or overall functionality.

Both versioning systems have their pros and cons. But as I explained in my earlier comment, we either artificially slow down feature rollouts, or release major bumps without real prominent changes, or stay on the current major version forever.

That said, since Joe is opposed to it and @Jamie hasn’t expressed much interest either, I don’t mind keeping things as they are and figuring out how to deal with it as we go. Maybe we just bump major versions when we introduce breaking changes, like specific updates to the installer or changing Webmin to be modular.

What’s still more important, in my opinion, is improving the GitHub repo organization—as I explained in great detail in my other post:

Consolidate all our GitHub repos under the `webmin` organization

I’d like to suggest reorganizing our projects on GitHub, as some of them currently make little sense—I’ll elaborate on that further. We’ve discussed this before privately with @Joe and @Jamie, but it didn’t turn out to be very productive. The key point—and a very simple change—is that webmin should be the single organization in GitHub hosting all our code and repositories, rather than splitting things across separate organizations like virtualmin. That said, it makes far more sense to have rep…