WIP release: next release

[monperrus]

The last release was 4 months ago (Oct 27 2021)

Since @algomaster99 repaired CD, merging this PR is the only task to release 10.0.1, in theory.

[slarse]

There are at least two commits since the last release that are marked as feature:

• af5774e
• 7c01e62

So, how about a minor version increment? I'm just assuming we're following semantic versioning here.

[monperrus]

We're not strictly following SemVer (which I'm not a big fan of btw). The last digit is mostly used for emergency patching.

A lot has happened since Oct 27 2021, we want to signal this quantity with the new version number. I've added the changelog in this PR description with that respect.

So we may proceed with 10.1.0 to make it clear that this new version contains serious new stuff.

[slarse]

We're not strictly following SemVer (which I'm not a big fan of btw).

So what are we following? Versioning is meaningless if those consuming (or, apparently, maintaining) the library don't know what a bump of any given version entails.

So we may proceed with 10.1.0 to make it clear that this new version contains serious new stuff.

But won't merging this PR just release version 10.0.1? As I recall, the release script simply takes the previous version and removes the snapshot suffix.

[monperrus]

So what are we following?

Yes, let's document this first. See #4646.

[monperrus]

Now that we agreed that the last digit is HOTPATCH for broken releases #4646, we can proceed with this one.

[slarse]

@monperrus But this is still wrong according to the docs you just merged. This bumps the patch version number from 10.0.0 to 10.0.1, but the release contains new features. Consequently, at the very least, we should release 10.1.0.

[xzel23]

@monperrus I can only support @slarse here: the new release supports so many new language features that I would at least go to 10.1.0. I don't know about sealed classes, but I think I use every other new Java 17 language feature in the code that I process with SPOON and 10.0.0 was more or less useless with most that was introduced since 11 was released. For me, the new release has added Java 17 support (although I cannot tell if it is complete), which is not a hotfix, but a major new feature.

[monperrus]

I'm all for 10.1.0. Here we have a technical limitation of our CD pipeline. If we want to release 10.1.0 in this PR:

1. I make a second commit
2. the integrator who merges does not squash

However, 2) is impossible per the repository set up.

The other alternative is to merge this one. And just after to bump to 10.2.0. This would achieve the desired effect, and 10.0.1 and 10.1.0 will be identical.

I'm fine with this pragmatic plan, waiting for an update of our CD pipeline.

[slarse]

This would achieve the desired effect, and 10.0.1 and 10.1.0 will be identical.

I would strongly say this is not the desired effect, as 10.0.1 is then effectively mislabeled. If we can easily revoke that version I suppose it's fine, otherwise I would object as it breaks the versioning scheme.

Wouldn't an easy way to solve this problem be to first merge another PR that just sets the version number to 10.1.0-SNAPSHOT, without making a release, and then merging this one with the version number set to 10.2.0-SNAPSHOT? Because unless I'm mistaken, the non-beta releases are still a manual process to deploy, correct (i.e. no accidental release on merge)?

[monperrus]

Because unless I'm mistaken, the non-beta releases are still a manual process

Not they are automated. But in a way which is not satisfactory, see SpoonLabs/spoon-deploy#5

Wouldn't an easy way to solve this problem be to first merge another PR that just sets the version number to 10.1.0-SNAPSHOT,

fully agree, this is #4660

In order to improve our CD pipeline, see SpoonLabs/spoon-deploy#6

Next step is to agree and merge SpoonLabs/spoon-deploy#5