Standard versioning schema?

Hello, thanks for Joplin, it's awesome.

I was looking after latest releases with some fixes I want and... well, I found out that Joplin uses a weird versioning system:

Yikes! It's hard to understand how this goes!

My proposal is to use a standard versioning system that helps everybody to understand what's going on. It may be a common standard or something made specifically for Joplin if those are not enough. Some standards I know and would probably fit:

  • semver. Widely adopted. It has the + symbol to indicate a version that has the same precedence, but has different build metadata. It might help for those android, ios, server variants... although I think that just sticking to alpha, beta, and rc should be enough for that case.
  • PEP 440. These days I tend to prefer this one, as it covers cases not covered by semver, which is sometimes too strict. For instance epoch or dev releases.
  • calver. Possibly not the best for joplin, but worth mentioning.

So, I'd expect that, if the next release is going to be v2.0.0, the releases above would look like this:

  • v1.8.5. Latest stable.
  • v2.0.0-alpha1. Includes server support.
  • v2.0.0-alpha2. More than server support.
  • v2.0.0-alpha3. Includes android support.
  • ... etc. You keep releasing alphas, then maybe betas or RC until v2.0.0 is finally released.

Also the alpha, beta and RC words say a lot per se about stability expectations.

1 Like

Is this a pre-release?

I don't know, it's written "Pre-release", so maybe it is? We won't add alpha, beta, etc. because it doesn't bring anything more than the pre-release system which we've used for years. We don't make major changes to our tooling and continuous integration just to please one user who's not sure if the "pre-release" label means that it's a pre-release.

Ok, it was just a suggestion :man_shrugging:

1 Like

The problem with the "Pre-release" label is that it's trapped on GitHub. If someone is installing from NPM or searching tags in the repository, there is no indication of pre-release embedded in the version string. I second the suggestion to put that information in the version string.

1 Like