Change release branch creation process to bump version to N.1.0.

[jyknight]

This will help distinguish release branch builds from development branch builds, and is similar to GCC's version numbering policy.

Thus, the branch releases/18.x will start out numbered 18.1.0, instead of 18.0.0.

Unchanged are other versioning policies:

• mainline will be numbered 18.0.0, 19.0.0, ...
• typical releaes branch releases will increment micro version, e.g. 18.1.1, 18.1.2, ....
• If an ABI break is required on the release branch, the minor version will be incremented, e.g. to 18.2.0.

See the Discourse RFC:
https://discourse.llvm.org/t/rfc-name-the-first-release-from-a-branch-n-1-0-instead-of-n-0-0/75384

[tstellar]

I don't have any objections to this, and I think I prefer this slightly over using $RELEASE_BRANCH_VERSION.99.0.

[h-vetinari]

I don't have any objections to this

Out of curiosity, in the RFC you said:

I think if we implement this proposal, we should also add the minor version to the SOVERSION. N.0.0 (trunk) would have a different ABI than N.1.0 (release branch).

Shouldn't this be done (or at the very least documented) with this PR? Otherwise it risks slipping through the cracks IMO.

[jyknight]

That question was directed at tstellar, so I'll wait for him to respond.

But, from my POV, while I think it's a fine idea (especially if we want to do an incompatible ABI on a release branch again), I don't think it's any more necessary after this proposal is implemented than it was before, so I am not expecting to make such a change, or even expect to make it a requirement that it be done in another PR before an 18.x release.

[tstellar]

@jyknight I'm fine making the change later. We can create an issue of this and added it to the release milestone so we don't forget.