> Am 14.12.2022 um 21:51 schrieb Basil Crow <[email protected]>: > > On Wed, Dec 14, 2022 at 12:37 PM Ullrich Hafner > <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2F84465D-F9CB-4452-A87E-D96BBD13EA3B%40gmail.com.
