[maven-release-plugin] prepare for next development iteration

[duncdrum]

Align versions between the standalone 6.3.0-branch and the ordinary develop branch for v6

[adamretter]

@duncdrum I advise against doing this. There is more than just the version number that has deviated between 6.3.0 and develop-6.x.x. Making this change will cause context to be lost.

[line-o]

Thanks @duncdrum for finding this. Don't you think we should change to 6.3.1-SNAPSHOT instead as this will be the next release?

[adamretter]

@line-o it would be better not to touch develop-6.x.x at all. If you need a hotfix, take it from the tag and/or branch for 6.3.0. Otherwise you will loose history and context

[dizzzz]

for me it is the 1st time that I read that develop-6.x.x should not be used for 6.x development? What is the "context to be lost." and how bad is it fro make a step right now in order to continue?

[line-o]

This step to raise the version number has happened in the past. I therefore re-opened this PR.

[adamretter]

Please consider comparing the git history between these things, and trying to understand why I am telling you all that you will lose context. I didn't create a release branch arbitrarily. As I did the last 22 releases (and many more before that too) I think you should consider that I might have a valid point here.

…

On Mon, 18 Nov 2024, 19:57 Juri Leino, ***@***.***> wrote: This step to raise the version number has happened in that past. I therefore re-opened this PR. — Reply to this email directly, view it on GitHub <#5547 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJUTOK2EYHMQFE4R232TX32BI2BDAVCNFSM6AAAAABRU6D6G2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBTHA3DKOBTGE> . You are receiving this because you commented.Message ID: ***@***.***>

[line-o]

@adamretter so the last time you cut a 6.x.x release (v6.2.0) it was done directly from this branch. Why did you choose to create a release branch this time?
Raising the version to 6.4.0-SNAPSHOT is sane and has happened in the past (see 9ade4cd).

[line-o]

As for the git history: Are your refererring to

• the revert commit that is only part of the release branch
• the release commits created by maven
• the git tag

or all of the above?

[adamretter]

Why did you choose to create a release branch this time?

As discussed with @dizzzz, I felt that develop-6.x.x was unstable in its current state due to a known memory leak that has been reproduced by three separate parties but remained unfixed (#4890).

Since I stopped being the Release Manager (>Feb 2022) the users of eXist-db had received no new release at all in the last 1 5/6 years, and no larger release in last 2 5/6 years. Therefore, I felt that if I was going to create a release, and as it might be a very long time before the users get another release after that, then I should make sure at this time to deliver to them a stable version of eXist-db that they can rely on.

Raising the version to 6.4.0-SNAPSHOT is sane and has happened in the past

In this instance that would not follow SemVer 2 principles, and it would corrupt the git history and lose commits and context. Creating a release branch was the right thing to do for 6.3.0. If you want a 6.3.1 release, you should create a new release branch from the 6.3.0 release branch, and then cherry-pick over any new hotfixes from develop-6.x.x that you need.

[line-o]

SemVer 2 principles were broken with the release of 6.3.0 (see https://semver.org/#spec-item-7) when binary fields were reverted.

[adamretter]

SemVer 2 principles were broken with the release of 6.3.0 (see https://semver.org/#spec-item-7) when binary fields were reverted.

@line-o Can you explain why you believe that please? I don't agree with that statement, I worked very hard to absolutely adhere to SemVer 2 principles (that I strongly believe in). The process which I believes adheres to SemVer 2 was:

1. eXist-db 6.1.0 did not have the binary fields
2. eXist-db 6.2.0 had the binary fields added which was a feature - so I bumped the minor version from 1 to 2.
3. eXist-db 6.3.0 had the binary fields removed which was both a feature change and a hotfix (to remove the memory leak that was introduced). As the feature change takes precedence over the hotfix, I bumped the minor version from 2 to 3.

[dizzzz]

As I interpreted it, removing the "binary fields removed" was a backwards incompatible change, and there are/were projects depending on it. Or do I overlook something and am I wrong here?

anyway with this pattern re-adding the feature (more tests are done in the mean while), would yield into the 6.4 version then. Which is in the end clear for end-users.

[adamretter]

@dizzzz Interesting. I perceived removing it as (a) a bugfix to remove a memory leak, and (b) a feature change. However, if removing it also changed an API signature, I didn't think it did at the time, but I can't double check right now, then it would have required a major version bump. If there was an API signature change, then I should have released 6.3.0 as 7.0.0, and if you wanted to add it back in, then that would have subsequently demanded a 8.0.0.

Apologies if I missed an API signature change, it was not my intention to break anyone's code.

[dizzzz]

No worries, it is a complex world here :-)