just to clarify as there are some points on this subject:

yes the breaking changes are already in a weekly release, but they are not 
in the upcoming LTS (2.263.1).

So yes I was proposing to change the version to 3.x before the new LTS.  
People using the weeklies are probably[1] already a bit more used to 
breakage or fixing things, and working out what may need to happen (they 
are more used to Jenkins) than say the LTS users who are less so, and may 
not even be Jenkins users but managing Jenkins in the IT department for 
some users.

Hindsight about maybe bumping the versions as things where merged is a 
great thing, but that horse has bolted - so we are really only discussing 
something after the fact that would potentially help LTS users, or those 
that do not regularly update their weekly release. 

/James

[1] pure gut feeling, I have no data whatsoever to back this up

On Friday, November 27, 2020 at 9:44:56 AM UTC Raul Arabaolaza wrote:

> Hi all,
>
> I believe it may make sense to use different versioning schemes for LTS 
> and weekly?.
>
> Semver and 3.x bump makes a lot of sense for LTS lines as the breaking 
> changes may have been made public in the weekly but not in the LTS so we 
> are still on time. Also LTS target audience, I guess, is much more worried 
> about compatibility than weekly users so a semver versioning could help a 
> lot.
>
> About weekly I fully agree with the date based versioning
>
> Regards  
>
> On Friday, November 27, 2020 at 4:55:44 AM UTC+1 [email protected] 
> wrote:
>
>> I don't think anyone is arguing against the benefits of semantic 
>> versioning. Its really great for the reasons listed for the end user.
>> It is however, much harder to implement reliably in open source, when 
>> there's a lot of changes made by a lot of people. I know when I was 
>> involved with blue ocean, people got pissed at us when we released a change 
>> as a minor instead of major or patch or whatever. Something always breaks 
>> someones infra.
>>
>> I like the idea of the very clear dated releases. It makes support a lot 
>> easier eg. "Oh your release was from november of last year, you should 
>> upgrade" "okay, your using 2.65, when did that get released? oh 2 years 
>> ago?" Like I never have to think when Ubuntu 20.04 came out, I know it was 
>> more or less april of this year. The tricky thing is how would dates work 
>> with LTS releases. It would be odd to have Jenkins 20201114-3 being 
>> released in early 2021.
>>
>> I'm not sold on 3.x as major changes have already gone out, but i'm not 
>> against 3.0 either, and its nice for a marketing push but as oleg 
>> mentioned, it might clash with jenkins x.
>>
>> So.. i guess i'm +/- 0 then?
>>
>> Gavin
>>
>>
>>
>> On Thu, Nov 26, 2020 at 7:33 PM Beryl Snyder <[email protected]> wrote:
>>
>>> 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
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAKDA9fRDGBe8KQJHSzKy-cHfzJbsgZozMB76YvLKZhNnGZtmow%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/71c2a1b9-e1ce-4a74-a5ee-732cd217d6fbn%40googlegroups.com.

Reply via email to