Hi Ralph, On Mon, 11 Dec 2023 at 22:43, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > The rule for this seems extremely simple to me. The changelog uses > > <simpleType name="changeType”> > <restriction base="string”> > <enumeration value="added”/> > <enumeration value="changed”/> > <enumeration value="deprecated”/> > <enumeration value="removed”/> > <enumeration value="fixed”/> > </restriction> > </simpleType> > > If every entry is deprecated or fixed it is a patch release. Everything else > is a minor release. Yes, I realize that you can add, change or remove things > without impacting compatibility but whether it is a patch or minor release > isn’t about compatibility.
I agree this should be the algorithm, but this only moves the problem one step down: * we lack a way to classify dependency updates. A concrete example: did the Commons DBCP2 bump to 2.11.0 change anything in `log4j-jdbc-dbcp2`? I don't think so, the artifact compiles with version 2.2.0 of the artifact. We are only stating that `log4j-jdbc-dbcp2` will **also** work with version 2.11.0. I don't think this warrants a minor version bump. * we lack a type to classify internal changes to the build system. The bump to JDK 17 was necessary, very useful for us, but users don't really care what JDK was used for compilation. It is the same situation as with dependency bumps: we are only stating that our artifacts work **also** on JRE 17, which is rather a bug fix instead of a minor version bump. Lacking a special "upgraded" type I would classify those changes as "fixed", hence a patch level change. Piotr
