Increase version number

[mgmax]

We are now at version 1.9 since maybe five years. I would suggest we take the step to 2.0 before some larger changes like removing the FabQR feature #692 . Any opinions?

[TheAssassin]

I'd rather call the removal a chance for a major release. It's a breaking change. I'd merge it beforehand.

Edit: I would also propose releasing more regularly after a "stable" major version has been released. VisiCut contains so many great new features nowadays, and using a "development" build all the time is just a bit inconvenient and hard to justify.

[mgmax]

For simplicity and due to limitations of the build system, I now pushed the 2.0 version and the breaking changes will be following in 2.0-x.

I fear we currently don't have the time to do a proper separation of development and release versions, so let's just bump the version number from time to time so users can go back to a "known old" version when they are unhappy.

[TheAssassin]

Breaking changes should follow in a 3.x, 4.x etc. It's not necessary to strictly follow semver, but I also think breaking changes should cause a major release.

[mgmax]

The issue is with the current build tooling and/or the way we use it:
If you tag 2.0 and then make one commit with a breaking change, you have 2.0-1. So we have to tag a new version for every single commit with important changes, which would lead to extremely large version numbers. Or change our approach or tooling.

@t-oster The build server got stuck after I had to force-push a tag. Can you please have a look?

[t-oster]

@mgmax the build server is fixed. I don't really get your point with the version scheme? We use 2.x tags to track important non-breaking features and the -y suffix is the number of commits since the last tag, which should be used for minor fixes/additions which aren't worth a new version number. IMHO this is pretty much semver, so what is your suggestion?

[mgmax]

Let me explain my issue better.

Expected:

• Version "1.9-123" has no breaking changes to Version "1.9-1".
• Version "2.0-1" has relevant changes compared to "1.9-123".
• Version "2.0-11" has no breaking changes to Version "2.0-1".
• Version updates (1.9 -> 2.0 -> 2.1) happen not too often, e.g., not every week.

Given:

1. The current version is 1.9-123.
2. I tag the current version with 2.0. (Maybe make a pseudo-commit).
3. I make 10 breaking changes in the same week (or one large breaking change in several steps).
   I don't want to make version update (e.g. 2.1 ... 2.11) for each of these steps.

Actual result:

• Version "2.0-1" (from step 2) has no interesting changes compared to "1.9-123"
• Version "2.0-11" (from step 3) has breaking changes compared to "2.0-1".

[TheAssassin]

I think you've kind of over-engineered that last number. Is there any reason not to "upgrade" (well, change) to another scheme, though? Semver is in widespread use and it has some easy to follow rules.

3.0.0 would be the initial release following this scheme, with 3.1.0 being the first release bringing new features and 3.0.1 the first release with just patches. It doesn't take a lot of thought to tag a new release then.

I introduced semver in the past into other projects to streamline the version numbers across an organization with great success. Semver also doesn't have that limitation of 10 releases.

[TheAssassin]

Addendum: I still think it makes sense (also to increase external contribution) to move all of the CI/CD toolchain to GitHub. A PR introducing this will be opened soon, I'm fixing the last few bugs/problems. See #670.

[mgmax]

Currently, the last part of the version number is created automatically. Every commit is "released" (uploaded to the build server) automatically.

That's the main difference between VisiCut and other projects like Inkscape. For Inkscape, you have releases like 1.3.2 and not-yet-released nightly builds like 1.4.0-dev+202403021335+025a20f373. With VisiCut's tooling, this 1.4.0-dev would be named, e.g., 1.3.2-42.

[TheAssassin]

I am aware of this. It's basically git describe --tags. That, however, is not incompatible with semver.

Please see #710 for instance. Non-tag releases (prereleases, continuous releases) use a <last-known-tag>-<distance> scheme. It doesn't matter at all whether it is 2.1.0-123 or 2.1-123.

[mgmax]

According to semver, 1.2.3-xx < 1.2.3 < 1.2.4-xx < 1.2.4 ("When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version"). However, in the repository, 1.2.3-xx comes after 1.2.3.

Let's just ignore that for now as long as we have more important issues :-)

[TheAssassin]

Fascinating. I've never seen that kind of pattern before. But then again, I don't want to suggest it needs to be adhered to strictly. git describe --tags works perfectly for so many projects...