Looking at this as someone who is more of a sysadmin(this is for the LTS releases), I like semantic versioning because I want to know when an upgrade will likely break things. It gives me an idea of how much time I need to burn stuff in/warnings to give and test before I promote from the testing environment. That said, any pattern is workable, I would ask: 1) if you don't do semantic versioning don't make it look semantic 2) any breaking changes are very clearly communicated (if i'm going to jump 2 or 3 releases i'm going to at most skim the release notes)
Regards, Beryl On Thu, Nov 26, 2020 at 10:44 AM Baptiste Mathus <[email protected]> wrote: > TBH, I'd just embrace the more and more common yyyy-mm-dd ish pattern of > releases. > > It would kind of make this clearer to outsiders that the version numbers > of Jenkins are close to nothing related to stability but more a very > regularly recurring release pattern. > > _Maybe_ I'd then agree with you for some new/adjusted version scheme *for > LTSes*, but not worth doing this for weeklies IMO. > > It's *my* very personal opinion, fwiw. > > -- Baptiste > > Le mer. 25 nov. 2020 à 17:37, James Nord <[email protected]> a écrit : > >> Hi all, >> >> with the recent weeklies we have a couple of changes (Acegi >> upgrade/table-to-div) that break compatibility in plugins. >> >> Whilst many open source plugins have been updated and made compatible >> with the old and new version by the people making the changes (and >> compatability layers have been added as far as possible), there can be >> closed source ones that we have no sight of that can be broken. >> >> Given this is an API compatibility breakage, I am wondering why don't we >> bump the version number to Jenkins 3.x to signify the breaking API? >> >> Regards >> >> /James >> >> -- >> 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/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAKDA9fRDGBe8KQJHSzKy-cHfzJbsgZozMB76YvLKZhNnGZtmow%40mail.gmail.com.
