Re: Jenkins 3.x

[Richard Bywater]

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,  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  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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/bdc030e7-24c9-477c-a7ea-064e4e106421n%40googlegroups.com
> 
> .
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwfi%2BGxqS2WR-1AzpSLB3BJH2%3D7fmGLGMmZzfM-cfGj2qw%40mail.gmail.com.

Re: ExtensionFinder$GuiceFinde ClassNotFoundException

[Oleg Nenashev]

Hi! Your plugin needs the Jira REST Client library, bit it looks like it 
was not loaded on the Jenkins startup. Most likely it means that the 
library was not added to the plugin HPI and was not provided by another 
plugin. If you could share your pom.xml, it might help to pinpoint the issue

On Friday, November 27, 2020 at 9:47:41 PM UTC+1 mikeyca...@gmail.com wrote:

> Trying to add Jira functionality to a parameter.   I get this when it 
> starts up.   Classes aren't getting loaded into what ever space the 
> parameters are loading into.
>
> Am I missing a white list or something?
>
> 2020-11-27 20:39:04.321+ [id=42] WARNING 
> h.ExtensionFinder$GuiceFinder$SezpozModule#configure: 
> Failed to load io.jenkins.plugins.JenkinsPlugin.JiraPack
> java.lang.ClassNotFoundException: 
> com.atlassian.jira.rest.client.internal.async.AsynchronousJiraRestClientFactory
> at 
> jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1387)
> at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1342)
> at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1089)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> Caused: java.lang.NoClassDefFoundError: 
> Lcom/atlassian/jira/rest/client/internal/async/AsynchronousJiraRestClientFactory;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
> at java.lang.Class.getDeclaredFields(Class.java:1916)
> at 
> hudson.ExtensionFinder$GuiceFinder$SezpozModule.resolve(ExtensionFinder.java:503)
>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/e9d7e30f-397a-4789-86af-33c90b0b91fbn%40googlegroups.com.

Re: Jenkins 3.x

[Oleg Nenashev]

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  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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/bdc030e7-24c9-477c-a7ea-064e4e106421n%40googlegroups.com.

Re: Jenkins 3.x

[Daniel Beck]

> On 27. Nov 2020, at 18:26, James Nord  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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/DF8247AA-3945-4720-8E73-D050C16383A9%40beckweb.net.

Re: [LAST CALL] - Jenkins 2020 Elections voter registration, deadline on Nov 24

[Oleg Nenashev]

Just a reminder, the Jenkins 2020 election polls will close in less then 2 
hours.
If you have registered for voting but have not voted yet, please do it ASAP

On Wednesday, November 25, 2020 at 2:07:04 PM UTC+1 Oleg Nenashev wrote:

> Hello,
>
> Thanks to everyone who registered for the elections! The registration 
> period is now over, and we have closed the registration form. All new 
> registrants should have received the ballot emails from CIVS or the 
> clarification request emails.
>
> The deadline for voting is Nov 27, 11PM UTC. If you do not see the ballot 
> emails, please follow the guidelines in the previous email.
>
> Best regards,
> Oleg Nenashev
>
>
>
> On Tue, Nov 24, 2020 at 5:26 PM Oleg Nenashev  wrote:
>
>> Dear all,
>>
>> This is the last reminder about voter registration for the 2020 
>> elections. The sign-up will be closed in less than 24 hours. If you would 
>> like to cast your vote during the elections but have not registered yet, 
>> please do it as soon as possible (voter registration guide 
>> ,
>>  
>> registration form ).
>>
>> For more information about the candidates and the process, see this 
>> blogpost .
>>
>> *Already registered? *Thanks to everyone who has already voted! If you 
>> have registered but not voted yet, the deadline is Nov 27, 11PM UTC. If you 
>> have not received the ballot, here are notes:
>>
>>- We have verified all election registrations. If you registered 
>>using the Google Form or the email, you should have received two voter 
>>ballot emails OR a clarification request from the Jenkins 2020 election 
>>committee members. All emails have been sent to the email addresses 
>>specified during the registration
>>- If you have not received the emails yet, check your inbox. Here is 
>>data for search:
>>   - From: Jenkins 2020 Elections Committee (CIVS poll supervisor) <
>>   ci...@cs.cornell.edu>
>>   - Email titles: "Poll: Jenkins 2020 Governance Board Election"
>>- If you cannot find the email, please contact jenkins-2020-elections@
>>googlegroups.com
>>
>> Best regards,
>> Oleg Nenashev
>> Jenkins 2020 Elections Committee
>>
>>
>>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/00ddd520-0f09-45a3-b2fe-2262388efcddn%40googlegroups.com.

ExtensionFinder$GuiceFinde ClassNotFoundException

[Michael Carter]

Trying to add Jira functionality to a parameter.   I get this when it 
starts up.   Classes aren't getting loaded into what ever space the 
parameters are loading into.

Am I missing a white list or something?

2020-11-27 20:39:04.321+ [id=42] WARNING 
h.ExtensionFinder$GuiceFinder$SezpozModule#configure: 
Failed to load io.jenkins.plugins.JenkinsPlugin.JiraPack
java.lang.ClassNotFoundException: 
com.atlassian.jira.rest.client.internal.async.AsynchronousJiraRestClientFactory
at 
jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1387)
at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1342)
at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1089)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
Caused: java.lang.NoClassDefFoundError: 
Lcom/atlassian/jira/rest/client/internal/async/AsynchronousJiraRestClientFactory;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
at java.lang.Class.getDeclaredFields(Class.java:1916)
at 
hudson.ExtensionFinder$GuiceFinder$SezpozModule.resolve(ExtensionFinder.java:503)

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/f98c6431-298a-4437-9ce7-42ce54bb549bn%40googlegroups.com.

Re: Jenkins 3.x

[James Nord]

>  if we go for 3.x, should we also change the versioning scheme? Can this
come later? I think any discussions regarding versioning schemes should go
together with a proper deprecation & removal policy. We could use this
chance, for example, to say "we're removing prototypejs in 2 years, by
version X". That's why I think it may be a bit out of scope for this
discussion (IMO).

Could we maybe keep the discussion here to just a 3.x bump as we are more
likely to reach a consensus?
we have tried and failed to get a deprecation policy for a long time - and
I doubt we have enough time to do it before the next next LTS release

changing to a different version scheme using .WW would still be
possible after the fact as 2020 is > 3  should there also be a consensus in
a follow up.

>  How could we do it? We cannot ignore the fact that we are 5 weeklies in
after the changes have been merged.

we just change the version in the weekly and say Hey we are calling this
3.1 and we are a little late.  We do not have to be perfect

/James


On Fri, 27 Nov 2020 at 16:04, Victor Martinez 
wrote:

> +1 for the 3.x as a statement of intentions to the end users and +1 for
> the time-based release versioning.
>
>
> On Friday, 27 November 2020 at 12:03:21 UTC fque...@cloudbees.com wrote:
>
>> I wouldn't object to bumping the version to a major (3.x). There are
>> enough changes, even if they are not that impressive to average users. That
>> said, I have some questions.
>>
>>- How could we do it? We cannot ignore the fact that we are 5
>>weeklies in after the changes have been merged.
>>- If we go for 3.x, should we also change the versioning scheme? Can
>>this come later? I think any discussions regarding versioning schemes
>>should go together with a proper deprecation & removal policy. We could 
>> use
>>this chance, for example, to say "we're removing prototypejs in 2 years, 
>> by
>>version X". That's why I think it may be a bit out of scope for this
>>discussion (IMO).
>>
>>
>> On Friday, November 27, 2020 at 12:26:49 PM UTC+1 ullrich...@gmail.com
>> wrote:
>>
>>> >
>>> > 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 think a scheme similar as used for IntelliJ would work as well for us,
>>> we can use weeks rather then milestones: year.week.patchlevel
>>> I would not recommend to use the exact dates in the version as this is
>>> harder to correctly write in bug reports.
>>>
>>> So 2020.30, 2020.31, and so on for the weekly releases, and 2020.30.1,
>>> 2020.30.2, and so on for LTS release.
>>>
>>>
>>> --
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/341c82d4-1d1b-4886-a1c3-7e3b7ffa0c7an%40googlegroups.com
> 
> .
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPzq3pfrqzQ3CL0dSeZ164TmCx1UytgOcKdbYq0%3DtQt1n%2BoJog%40mail.gmail.com.

Re: Jenkins 3.x

[Victor Martinez]

+1 for the 3.x as a statement of intentions to the end users and +1 for the 
time-based release versioning.


On Friday, 27 November 2020 at 12:03:21 UTC fque...@cloudbees.com wrote:

> I wouldn't object to bumping the version to a major (3.x). There are 
> enough changes, even if they are not that impressive to average users. That 
> said, I have some questions.
>
>- How could we do it? We cannot ignore the fact that we are 5 weeklies 
>in after the changes have been merged.
>- If we go for 3.x, should we also change the versioning scheme? Can 
>this come later? I think any discussions regarding versioning schemes 
>should go together with a proper deprecation & removal policy. We could 
> use 
>this chance, for example, to say "we're removing prototypejs in 2 years, 
> by 
>version X". That's why I think it may be a bit out of scope for this 
>discussion (IMO).
>
>
> On Friday, November 27, 2020 at 12:26:49 PM UTC+1 ullrich...@gmail.com 
> wrote:
>
>> > 
>> > 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 think a scheme similar as used for IntelliJ would work as well for us, 
>> we can use weeks rather then milestones: year.week.patchlevel
>> I would not recommend to use the exact dates in the version as this is 
>> harder to correctly write in bug reports.
>>
>> So 2020.30, 2020.31, and so on for the weekly releases, and 2020.30.1, 
>> 2020.30.2, and so on for LTS release. 
>>
>>
>>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/341c82d4-1d1b-4886-a1c3-7e3b7ffa0c7an%40googlegroups.com.

Re: Jenkins 3.x

[fque...@cloudbees.com]

I wouldn't object to bumping the version to a major (3.x). There are enough 
changes, even if they are not that impressive to average users. That said, 
I have some questions.

   - How could we do it? We cannot ignore the fact that we are 5 weeklies 
   in after the changes have been merged.
   - If we go for 3.x, should we also change the versioning scheme? Can 
   this come later? I think any discussions regarding versioning schemes 
   should go together with a proper deprecation & removal policy. We could use 
   this chance, for example, to say "we're removing prototypejs in 2 years, by 
   version X". That's why I think it may be a bit out of scope for this 
   discussion (IMO).


On Friday, November 27, 2020 at 12:26:49 PM UTC+1 ullrich...@gmail.com 
wrote:

> > 
> > 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 think a scheme similar as used for IntelliJ would work as well for us, 
> we can use weeks rather then milestones: year.week.patchlevel
> I would not recommend to use the exact dates in the version as this is 
> harder to correctly write in bug reports.
>
> So 2020.30, 2020.31, and so on for the weekly releases, and 2020.30.1, 
> 2020.30.2, and so on for LTS release. 
>
>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/973dd22a-cc5b-4640-935c-f729ce6a2979n%40googlegroups.com.

Re: Jenkins 3.x

[Ullrich Hafner]

> 
> 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 think a scheme similar as used for IntelliJ would work as well for us, we can 
use weeks rather then milestones: year.week.patchlevel
I would not recommend to use the exact dates in the version as this is harder 
to correctly write in bug reports.

So 2020.30, 2020.31, and so on for the weekly releases, and 2020.30.1, 
2020.30.2, and so on for LTS release. 


-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/E40815F5-E8B5-4B4C-88D7-9CC8715403DA%40gmail.com.

Re: Jenkins 3.x

[jn...@cloudbees.com]

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 ga...@gavinmogan.com 
> 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  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  
>>> wrote:
>>>
 TBH, I'd just embrace the more and more common -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  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 

Re: Jenkins 3.x

[Raul Arabaolaza]

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 ga...@gavinmogan.com 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  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  wrote:
>>
>>> TBH, I'd just embrace the more and more common -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  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 jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com
  
 
 .

>>> -- 
>>> 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 jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop