search

t-oster / VisiCut

A userfriendly tool to prepare, save and send Jobs to Lasercutters
https://visicut.org
Other
235 stars 115 forks source link

Increase version number #702

Closed mgmax closed 8 months ago

mgmax commented 9 months ago

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 https://github.com/t-oster/VisiCut/pull/692 . Any opinions?

TheAssassin commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

@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 commented 8 months ago

Let me explain my issue better.

Expected:

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:

TheAssassin commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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...