I do not think switching to a 3.x version number accomplishes much of anything (even if we had done so several weeks ago, when the big changes were landing). I would much rather see Jenkins switch to either a date-based scheme, or just some opaque incrementing number like we have but without the meaningless `2.` prefix. Jenkins releases break compatibility for someone, somehow, all the time; a number tells you nothing about whether _you_ will be affected. We need to publish clear, concise upgrade guides; encourage users to make backups or use a config-as-code workflow; and of course try as hard as we can to not break compatibility to begin with! In the case of JEP-227 & JEP-228 there have already been extensive plugin fixes released and few users should actually be affected. Tables-to-divs has apparently caused more regressions, but these should all be fixable long before the LTS.
In theory SemVer could be useful for libraries. In practice it seems like a false promise to me. It is your tests which will tell you if an upgrade is compatible, not some upstream maintainer’s fantasy. Dependabot actually _keeps score_ and tells you whether a given update broke CI for other people, which seems like far more valuable information. -- 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/CANfRfr0JZtW1x17eeUSVQzfAJgck08jVnfZ0%3DN4reZZ7RYx6fA%40mail.gmail.com.
