Moving Mailinabox to semantic versioning?

Hello,

I would like to discuss about how Mailinabox versions are defined.

Since it started, Mailinbox versions are incrementing major updates over 0 like 0.52, 0.53 with optional letters for minor updates like 0.53a, 0.53b, 0.53c…

It bothers me at this time because software versions below 1.0.0 means “not finished, use with caution”.

But, since then, Mailinabox did prove its maturity and efficiency, with a growing number of users all over the world.

I think it’s time to give Mailinabox a proper and well deserved 1.0.0 version number.

In addition, we now have a standard called Semantic Versioning to give meaning to softwares versions : https://semver.org/.

A major version update indicates a breaking change, a minor version update indicates a new feature in a backwards compatible manner, and a patch version update indicates backwards compatible bug fixes.

It gives a level of information about updates without the need to read the changelog. It there is a non-major update, we know we can update safely.

How do you think?

PS. Mailinabox also jumped over 54 versions in one update from 0.54 to 55 :laughing:

Capture d’écran du 2022-02-19 12-52-37

I reckon that because MIAB is a product made towards end users and not developers, that the concept of exposing an API is actually secondary. Therefore Semver is not necessarily the be-all end-all solution for this.

The maintainer decided to just drop the 0. part of the version and continue from there.

I appreciate that you think the project is stable enough for 1.0-style versioning. :slight_smile:

As @davness mentioned, I just changed the versioning scheme, so I don’t want to make another change so soon. But I think the real difficulty would be deciding what counts as a minor or patch change since I think every release has been backwards compatible.

What’s an example of something updated that wasn’t safe? I can try to make the changelog clearer about those sorts of things.

@davness @JoshData I thought that the switch from v0.X to vXX was actually a typo of some sort :laughing:

It’s totally OK to start at 56.0.0 to take into account the Mailinabox history so the switch remains smooth. If Mailinabox never do breaking changes, then it will be only 56.X.X versions in the future and the version numbers will actually scream that Mailinabox is always backward compatible. It’s a first improvment!

But I still can think of breaking changes like the switch from Owncloud to Nextcloud that affected third party apps integration, or a change on existing scripts (which are the public API of Mailinabox) like a rename or something.

Yes these changes are not likely to happen, but since Mailinabox rely of third party softwares, they may add breaking changes in the future forcing Mailinabox to follow. For example, Nextcloud or Roundcube could decide in the future to force the use of some sort of 2 factor authentication, or a new authentication protocol preventing Mailinabox to sync user passwords.

I also can think of a huge breaking change which will happend every 3 or 4 years: when Mailinabox ismoving to the latest LTS Ubuntu version. For example, we cannot know without reading changelog that v0.30 and > v0.31 are not meant to run on the same OS. I think it’s worth it, if only for that point !

It costs nothing and will give additional info, while moving to a standard :slightly_smiling_face:

SemVer is too complicated. To quote Josh:

what counts as a minor or patch change

This is purely subjective, whereas incrementing a number is much clearer.

we cannot know without reading changelog

Removing responsibility from yourself to the project owner(s) is in poor taste IMHO. Don’t update unless you know what you’re updating to. RTFM.

Personally, I prefer the chronological versioning (2022.02.19, for example) because you can tell at a glance when the last time an update happened.

My final point, look at the versioning your OS uses. It’s probably not SemVer and SemVer is not a salve for every project.

You are completely right, Semantic Versioning is not a silver bullet (there are few such things in software).

You are also right by saying that not all operating system are using SemVer (though, MacOS does).
Ubuntu uses a chronological versioning (for example, 20.04 stands for april 2022, 21.10 for october 2021) as well as Windows (Windows 10 version 1507 stands for jully 2015).

That being said, despite the fact that they’re using chronological versioning, they give meaning about what’s breaking or not because they follow a specific versioning convention.

Ubuntu versions are released twice a year in april and october, all april versions are LTS ones, the october ones contains the breaking changes that will be in the next LTS.

It is thanks to meaningful versions that Mailinabox team knows that must choose an april version ( like 14.04 or 18.04) to not have to think about the update for 4 years (supported time of LTS versions).

I am telling you that to show that meaningful versions are useful also for softwares that have long period releases.

If it’s not Semantic Versioning, it can be another meaningful versioning convention, I proposed this one because it’s the one I know (I am not of the dogmatic kind that want to impose his vision everywhere :stuck_out_tongue:).

The thing is, as a Mailinabox user, it bothers me because it’s one of the one of the only software I use that I don’t update regularly because I know that I have to check the release notes each time (the next Mailinabox release can be the one moving to 20.04) and I don’t have the time to do that every time.

That’s bad because nowadays software security is about making updates as fast as possible.

But you are right, it’s my entire responsibility.

By writing this post, my first thought was to remove the fear of the 0.X version for such a great software (because people that do not use softwares because of version below 1 is a thing and they are probably right most of the time). But this is already fixed.

The second was about improving user experience by giving meaningful versions to Mailinabox users.

We can argue that it does not worth it, that Mailinabox does not need a better user experience, or not at this (so high) cost. We can disagree about the fact that giving meaningful version is improving user experience (maybe I am the only one who can see a benefit with it).

But I am obliged to reject all other arguments (sorry :p). The confusion between minor and patch version is actually not what matters. What matters is what breaks or not.

This is this information that Mailinabox version number does not give.

And this cannot be also more complicated nor more subjective that the actual versioning system because we already have distinction between patches and the minor & major version (with v0.53a, 0.53b…, it’s exactly the same thing of having 1.53.1, 1.53.2).

In any case, It’s only a suggestion (and my opinio. If meaningful versions (semantic or not) becomes a thing one day, you know that you’ll make at least one happy man.

Cheers!

1 Like

I’m not going to weigh in on the whole version number discussion because I don’t have a strong opinion.

The versioning works just fine for me the way it is, but I can see some of the logic in the above.

But…

I personally check the release notes for an update to any major piece of production software before updating anything, it seems kind of crazy not to.

1 Like

This topic was automatically closed after 61 days. New replies are no longer allowed.