> Am 14.12.2022 um 21:51 schrieb Basil Crow <m...@basilcrow.com>: > > On Wed, Dec 14, 2022 at 12:37 PM Ullrich Hafner > <ullrich.haf...@gmail.com> wrote: >> >> I would suggest to always update the major version of our plugin-pom if we >> make breaking changes. This is the second time that we deliver incompatible >> changes with the same major version. > > Perhaps; we do not officially use semantic versioning or any other > scheme where breaking changes are tied to the version number, nor did > we bump the major version number of Jenkins core itself when making > the breaking change to require Java 11 or newer there (a decision made > after discussion on this mailing list). I could see both sides to this > one: while a new major version number would have been a more clear > signal to consumers that adaptations are needed, it also might have > implied a major feature release (which was not the case).
> The last > major version number bump in the plugin parent POM (4.0) was done by > James Nord, and that _was_ a major feature release. > I don’t think that you need to deliver new features when you increment the major version in an API (actually we delivered the new feature Java 11 with tons of changes) - at least semantic versioning does not require that. But they clearly define the following rule which makes sense for other version schemes as well: 1. increment the MAJOR version when you make incompatible API changes. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2F84465D-F9CB-4452-A87E-D96BBD13EA3B%40gmail.com.
