On Mon, 11 Dec 2023 at 20:33, Volkan Yazıcı <vol...@yazi.ci> wrote: > > In the end the result (release version number) might be the same, but > > the burden of proof falls on those advocating for a patch release. > > > > I don't understand what you mean by "the burden of proof falls on those > advocating for a patch release". Could you elaborate on it, please?
If you were to release Log4j right now from `2.x` what version would you use? Almost certainly 2.23.0, since: * the current snapshot version is 2.23.0-SNAPSHOT, * there is a 2.23.0 milestone: https://github.com/apache/logging-log4j2/milestone/9 The fact that the milestone contains only two patch-level changes is completely hidden. Either the Release Manager or the PMC members checking the release would have to go through those issues and prove that it is a 2.22.1 release. > As this conversation shows one more time, my main argument is against a > rule that is too open to interpretation. I prefer to have a rule that has > practically no room for ambiguity and at the same time makes sense in the > semver framework. Ambiguity is natural in the context of semver. We are supposed to convey a meaning, so we should try to categorize each change properly and discuss the changes hard to classify. There is a simple case: if BND says MINOR change, it is usually a minor change. However a change can always be upgraded due to reasons besides the public API changes. Regarding the classification of changes I also tend to look at our doc: * if the previous behavior disagreed with the doc, correcting it is a bug fix (we probably all agree), * if we change a previously documented behavior, it is a minor bump (here we also probably agree), * if we change a behavior that was **not** documented (e.g. the evaluation of lookups in user data ;-), we should discuss about it. > For the record, do you have a clear definition of your proposal? *"Every > release should be a patch release"* doesn't really help. I propose to keep the old strategy: after a release we set the version number to the next patch release. Only if we merge a change that requires a minor bump (we can tag those), we bump the release to the next minor version. Piotr PS: Of course the examples for Log4j are a little bit artificial, since Ralph's PR bumped the release number: https://github.com/apache/logging-log4j2/pull/2062
