My $0.02: Semantic Versioning is great for libraries; I'd certainly be in favour of migrating to it for plugins. For core, not entirely certain. In addition, you have PR labels that indicate when the changes require a major or minor version bump. Release drafter takes that into account (or should). So the actual version bump can be applied when cutting the release, to avoid issues where multiple PRs get merged and accidentally "overbump".
LTS releases are a bit of an issue in this regard. I'm not sure how they would be best handled. I suppose you could have SemVer for weeklies, then tack on a 4th number for the LTSes (so if an LTS branch is cut from 4.2.7, the LTS is 4.2.7.1). No longer SemVer then, but close enough (and my understanding is that LTS updates are for fixes only, not new API). It does mean that LTSes may go from 4.2.7.3 to 8.1.0.1 if there has been especially active development in that quarter's weeklies. I don't really see that as a problem, but some might. Note: I have nothing against a YYYY.MM[.1] schema either; it doesn't communicate anything about the amount/impact of changes it includes, but that's what release and upgrade notes are for. On Sat, 28 Nov 2020 at 00:06, Richard Bywater <[email protected]> wrote: > Just keeping an eye on the thread it seems to me that, before any decision > should be made about whether a bump to 3.x was done, a clear policy on > versioning really needs to be introduced on what constitutes a major > version bump so that it's clear that if xyz is implemented then that will > be done then we would need another version bump in the future. Otherwise we > run the risk of having this discussion time and time again. > > I think Jenkins 2.x made sense as it was quite a paradigm shift in the > usage of Jenkins not (as far as I can tell or remember - happy to be > corrected) anything to do with breakages or incompatibilities. It really > announced that pipelines were the way of the future for Jenkins and > therefore warranted a bump. > > I'm not sure this change really has the same thing going for it as (again > correct me if I'm wrong) we've had previous changes that have broken > plugins to require them to be updated with fixes or changes before it could > be upgraded? > > Personally I dont think closed source plugins breaking with the change > should be a major concern as long as we've clearly announced to plugin > owners that in version xyz your plugin will need a change as they should > really be keeping an eye on required changes as the majority I'd say are > getting paid money by customers for the service. > > Just my 2 cents :) > > Richard > > On Sat, 28 Nov 2020, 11:19 AM Oleg Nenashev, <[email protected]> > wrote: > >> There is clearly no consensus here, and IMHO we need to wait until the >> new Event officer takes the role. I doubt we can make a final decision by >> the next weekly release on Tuesday, so my suggestion is to keep discussing >> it and to also add it to the governance meeting agenda on Dec 02. >> >> On Friday, November 27, 2020 at 10:46:21 PM UTC+1 Daniel Beck wrote: >> >>> >>> >>> > On 27. Nov 2020, at 18:26, James Nord <[email protected]> wrote: >>> > >>> > Could we maybe keep the discussion here to just a 3.x bump as we are >>> more likely to reach a consensus? >>> >>> As a technical/compatibility indicator, 3.0 makes little sense because >>> it's late. None of the related documentation would even say "from Jenkins >>> 3.0" (if it did, it would be wrong). Plus there's no commitment to semver >>> in the future, making this not even useful from an admin POV as an >>> indicator that we're going to apply semver in the future. It might even be >>> actively bad to create an expectation that incompatible changes bump the >>> major version the next time we integrate a big change. People who read the >>> documentation before updating will see huge warning signs either way, and >>> can make an informed decision. People who don't will experience the same >>> pain either way. >>> >>> As a marketing/"there's big new stuff" indicator, I don't think there's >>> enough big new stuff here from a regular user POV. Ideally XStream and >>> Spring work without a ton of problems (and do we really want to highlight >>> how bad things were until now?), and tables to div is nice but not on the >>> scale I would expect as a user to justify the major version bump. All these >>> changes are mostly internal, with some nice but overall modest visual >>> updates to the configuration forms. Not to mention we'd need a solid plan >>> for announcements, documentation, etc. -- a lot of that nature was done for >>> Jenkins 2. >>> >>> To me, this idea comes at least a month late, probably two, and going >>> for it unprepared will just cause problems, while not actually >>> accomplishing much. >>> >>> -- >> 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/bdc030e7-24c9-477c-a7ea-064e4e106421n%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/bdc030e7-24c9-477c-a7ea-064e4e106421n%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/CAAy0hwfi%2BGxqS2WR-1AzpSLB3BJH2%3D7fmGLGMmZzfM-cfGj2qw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwfi%2BGxqS2WR-1AzpSLB3BJH2%3D7fmGLGMmZzfM-cfGj2qw%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/CAKMi--Brm2L9EsBkFp2nT8rN%3D0Ruwgefvahy0TxtBzZAK4YOqA%40mail.gmail.com.
