Re: Jenkins 3.x

[Oleg Nenashev]

Hi all,

Just a quick update for this and the related discussions:

   - As we discussed at the governance meeting, the Jenkins 3 discussions 
   were scheduled to the Jenkins Contributor Summit on June 25th 
   . 
   My plan was to have at least 3 hours of discussion of Jenkins 3 there, with 
   focus on delivering changes needed for reducing maintenance overhead, Java 
   17 support, and Jenkins paradigm changes to reflect the modern CasC 
   ecosystem and cloud environments.
   - I am sad to announce that I will be unable to drive this topic due to 
   the conflict of interest I was unable to resolve.
   - If there is any contributor interested in driving the conversation for 
   this topic, this is really good time to step up. I will be happy to help as 
   a contributor summit organizer.
   
Thanks to all community members who contributed by providing feedback and 
reviews for some of my ideas in other channels.I might have some time to 
drive this effort in the future, but I cannot do it now.

Thanks for understanding,
Oleg Nenashev
Engineer, CloudBees

On Wednesday, January 27, 2021 at 8:09:46 PM UTC+1 Jesse Glick wrote:

> On Wed, Jan 27, 2021 at 1:18 PM Tim Jacomb  wrote:
>
>> > Date based
>> […] any thoughts on the effort involved here in release automation?
>>
>
> I think this would most easily be done by ditching `maven-release-plugin`. 
> We have already done the tricky bits with `flatten-maven-plugin` etc. in 
> JEP-305. The JEP-229 system is the safest. You can also create a special 
> variant like
>
> mvn -Drevision=$(date -I) -Dchangelist= deploy
>
> plus some profile activation for `maven-javadoc-plugin` & 
> `maven-source-plugin` similar to what `produce-incrementals` does, plus 
> manual tagging, with the downside that snapshot & incremental builds will 
> not easily or safely compare properly to releases.
>

-- 
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/0ff2a4e6-564f-4822-b639-c0fd93fe515an%40googlegroups.com.

Re: Jenkins 3.x

[Jesse Glick]

On Wed, Jan 27, 2021 at 1:18 PM Tim Jacomb  wrote:

> > Date based
> […] any thoughts on the effort involved here in release automation?
>

I think this would most easily be done by ditching `maven-release-plugin`.
We have already done the tricky bits with `flatten-maven-plugin` etc. in
JEP-305. The JEP-229 system is the safest. You can also create a special
variant like

mvn -Drevision=$(date -I) -Dchangelist= deploy

plus some profile activation for `maven-javadoc-plugin` &
`maven-source-plugin` similar to what `produce-incrementals` does, plus
manual tagging, with the downside that snapshot & incremental builds will
not easily or safely compare properly to releases.

-- 
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/CANfRfr2eFdg2-oHsyN8gqfH3tpf4_2UG6OpZmfbFWU8BKwLj2g%40mail.gmail.com.

Re: Jenkins 3.x

[Tim Jacomb]

Hello

Few points

> Marketing
Definitely value in considering this, a 3.x and a big marketing push could
bring some good attention to Jenkins, but do we have enough big changes to
justify, possibly if we consider not just this LTS but other changes since
2.x.

Some other stories worth highlighting:
* GitHub checks integrations
* Plugin site new features, release notes, issues, and coming soon a report
a bug link taking you to creating an issue for the plugin
* Read only Jenkins
*  UX modernisation
* Couple of pluggable storage stories made some progress: test results and
fingerprints

> Date based
I support this, we'll never have a problem with hitting a .300 'minor
version' if we do this. @Olblak   any thoughts on the effort
involved here in release automation?

>  Number of breaking changes in weekly
I agree we could bump to 3.x to signal a higher upgrade risk, but agree
with others that the changes aren't too 'flashy'.
I like Felix's idea of doing some bigger UX re-work for a 3.x, but I'm not
sure we have enough contributors working in this area or time (assuming the
next LTS), given that the next LTS selection is starting now.

Thanks
Tim

On Tue, 26 Jan 2021 at 20:43, James Nord  wrote:

> > We do not have a fresh new massive story to share. At the same time
> there could be a few changes to highlight:
>
>- Adoption of Configuration-as-Code as a recommended way to manage
>Jenkins.
>- Making emphasis on Jenkins-in-the-cloud applications and packaging,
>with making Docker/Helm/etc. and downstream projects being promoted as
>first class citizens
>- Something else?
>
>
> There is k8s bits that did not exist in the past now.  The cloud auto
> provisioning of agents, some community helm charts (and I think a k8s
> operator, but I have never used it as CloudBees has a different
> implementation).
> There is soon (thanks to a PR) shotly going to be k8s secret support for
> both global and secret credentials (so mix C-asC and K8s in one)... (I
> should possibly do a blog post on that!)
>
> /James
>
> On Tue, 26 Jan 2021 at 11:26, Oleg Nenashev 
> wrote:
>
>> Marketing releases are indeed something we could consider. The next LTS
>> baseline selection starts this week, with ETA in early April. This release
>> will include a number of serious changes, and generally 3.0 might be
>> justified from the technical point of view. At the same time, it IMHO
>> requires a more fundamental change in Jenkins itself and its usage
>> paradigm. For example, in Jenkins 2 we were mostly promoting Jenkins
>> Pipeline and a few other related features, not the plugin unbundling as a
>> breaking change. If the whole point is about marketing, we need to prepare
>> well and to coordinate the rollout with CDF and key vendors so that we have
>> a big marketing push.
>>
>> We do not have a fresh new massive story to share. At the same time there
>> could be a few changes to highlight:
>>
>>- Adoption of Configuration-as-Code as a recommended way to manage
>>Jenkins.
>>- Making emphasis on Jenkins-in-the-cloud applications and packaging,
>>with making Docker/Helm/etc. and downstream projects being promoted as
>>first class citizens
>>- Something else?
>>
>> Anyway, I am not sure about taking the next LTS as 3.0. Tables to divs
>> story is likely to be a problem for users due to regressions in various
>> in-house and not popular plugins which have not been fixed yet. Thanks to
>> Tim, Raihaan, Felix and many other contributors for the cleanup, but I
>> doubt it will be as smooth as Jenkins 1->2 upgrade for the users.
>>
>> Best regards,
>> Oleg
>>
>> P.S: If we do a major release, it would be awesome to get the terminology
>> cleanup finished at least for the Jenkins core and major plugins. Taking
>> our announcements this summer, this is not the topic we should roll over to
>> Jenkins 3.
>>
>>
>> On Monday, January 25, 2021 at 6:53:59 PM UTC+1 msi...@cloudbees.com
>> wrote:
>>
>>> That's a good point. I still see people who don't know about pipelines
>>> even though they've been around since Jenkins 2.0 IIRC. The updated UI
>>> is also less well known.
>>>
>>> On Fri, Jan 22, 2021 at 9:23 PM Ming Tang  wrote:
>>> >
>>> > I think the release of Jenkins 3.x is very urgent. Let me put forward
>>> another very important reason: companies and users are abandoning Jenkins.
>>> Jenkins 2.x has a history of 5 years. In the past 5 years, Jenkins 2.x has
>>> many major features and incompatible modifications. The obsolescence,
>>> update, and requirements for higher 

Re: Jenkins 3.x

[James Nord]

> We do not have a fresh new massive story to share. At the same time there
could be a few changes to highlight:

   - Adoption of Configuration-as-Code as a recommended way to manage
   Jenkins.
   - Making emphasis on Jenkins-in-the-cloud applications and packaging,
   with making Docker/Helm/etc. and downstream projects being promoted as
   first class citizens
   - Something else?


There is k8s bits that did not exist in the past now.  The cloud auto
provisioning of agents, some community helm charts (and I think a k8s
operator, but I have never used it as CloudBees has a different
implementation).
There is soon (thanks to a PR) shotly going to be k8s secret support for
both global and secret credentials (so mix C-asC and K8s in one)... (I
should possibly do a blog post on that!)

/James

On Tue, 26 Jan 2021 at 11:26, Oleg Nenashev  wrote:

> Marketing releases are indeed something we could consider. The next LTS
> baseline selection starts this week, with ETA in early April. This release
> will include a number of serious changes, and generally 3.0 might be
> justified from the technical point of view. At the same time, it IMHO
> requires a more fundamental change in Jenkins itself and its usage
> paradigm. For example, in Jenkins 2 we were mostly promoting Jenkins
> Pipeline and a few other related features, not the plugin unbundling as a
> breaking change. If the whole point is about marketing, we need to prepare
> well and to coordinate the rollout with CDF and key vendors so that we have
> a big marketing push.
>
> We do not have a fresh new massive story to share. At the same time there
> could be a few changes to highlight:
>
>- Adoption of Configuration-as-Code as a recommended way to manage
>Jenkins.
>- Making emphasis on Jenkins-in-the-cloud applications and packaging,
>with making Docker/Helm/etc. and downstream projects being promoted as
>first class citizens
>- Something else?
>
> Anyway, I am not sure about taking the next LTS as 3.0. Tables to divs
> story is likely to be a problem for users due to regressions in various
> in-house and not popular plugins which have not been fixed yet. Thanks to
> Tim, Raihaan, Felix and many other contributors for the cleanup, but I
> doubt it will be as smooth as Jenkins 1->2 upgrade for the users.
>
> Best regards,
> Oleg
>
> P.S: If we do a major release, it would be awesome to get the terminology
> cleanup finished at least for the Jenkins core and major plugins. Taking
> our announcements this summer, this is not the topic we should roll over to
> Jenkins 3.
>
>
> On Monday, January 25, 2021 at 6:53:59 PM UTC+1 msi...@cloudbees.com
> wrote:
>
>> That's a good point. I still see people who don't know about pipelines
>> even though they've been around since Jenkins 2.0 IIRC. The updated UI
>> is also less well known.
>>
>> On Fri, Jan 22, 2021 at 9:23 PM Ming Tang  wrote:
>> >
>> > I think the release of Jenkins 3.x is very urgent. Let me put forward
>> another very important reason: companies and users are abandoning Jenkins.
>> Jenkins 2.x has a history of 5 years. In the past 5 years, Jenkins 2.x has
>> many major features and incompatible modifications. The obsolescence,
>> update, and requirements for higher versions of Jenkins core require
>> constant upgrading of Jenkins and modification of the configuration. This
>> is in the view of the end user (administrator) of Jenkins, but it is a toss
>> in the view of the leader. Small versions usually mean small changes. For
>> the leaders of Jenkins administrators, Jenkins 2.x is something that hasn't
>> changed a lot for many years, but it requires labor-intensive maintenance
>> and repeated exploration. The minor version upgrade hides the value of the
>> new version of Jenkins! News organizations do not pay attention to minor
>> version updates, and the leadership does not care about minor version
>> updates. Only the Jenkins administrator knows what Jenkins has updated!
>> Enterprises and users have begun to consider abandoning Jenkins! ! We need
>> to let the outside know that Jenkins is undergoing major changes, not that
>> it has not released a major version for 5 years.
>> >
>> > 在2020年12月3日星期四 UTC+8 上午2:02:20 写道：
>> >>
>> >> Interesting, first I had seen Revapi. Would be worth checking whether
>> >> it can replace japicmp in `jenkinsci/jenkins`, which I introduced as
>> >> part of JEP-227 but had to patch in order to properly handle
>> >> POM/classpath changes (and unfortunately that patch remains
>> >> unevaluated).
>> >
>> > --
>> > You received this message because you are subscribed

Re: Jenkins 3.x

[Daniel Beck]

The existing 1.x/2.x versioning scheme which only ever increases minor versions 
seems like it reinforces the idea that nothing is happening. Would going with a 
date-based versioning scheme help?

For example YY.nn (year and release, roughly corresponding to week in year), or 
YY.m.nn (year, month, and release). The former would even work (mostly) with 
existing assumptions around version format being 2 parts for weeklies and an 
additional third part for LTS.

Alternatively, we can do what browsers are doing and just make every release a 
top-level release. Given how frequently release this may end up looking silly 
sooner rather than later though. Browsers aren't in the hundreds yet, we've 
done it twice already.


> On 26. Jan 2021, at 12:41, fque...@cloudbees.com  
> wrote:
> 
> I would be 100% behind a change to Jenkins 3 if we do an actual major 
> release. For example, I would just nuke the current navigation system. I 
> think one major pain point is the lack of sane separation of global 
> navigation, local navigation and contextual actions. Redoing the whole 
> sidebar would affect many plugins, but it's the sort of change I'd expect 
> from a v3.
> 
> On Tuesday, January 26, 2021 at 12:25:58 PM UTC+1 Oleg Nenashev wrote:
> Marketing releases are indeed something we could consider. The next LTS 
> baseline selection starts this week, with ETA in early April. This release 
> will include a number of serious changes, and generally 3.0 might be 
> justified from the technical point of view. At the same time, it IMHO 
> requires a more fundamental change in Jenkins itself and its usage paradigm. 
> For example, in Jenkins 2 we were mostly promoting Jenkins Pipeline and a few 
> other related features, not the plugin unbundling as a breaking change. If 
> the whole point is about marketing, we need to prepare well and to coordinate 
> the rollout with CDF and key vendors so that we have a big marketing push.
> 
> We do not have a fresh new massive story to share. At the same time there 
> could be a few changes to highlight:
>   • Adoption of Configuration-as-Code as a recommended way to manage 
> Jenkins.
>   • Making emphasis on Jenkins-in-the-cloud applications and packaging, 
> with making Docker/Helm/etc. and downstream projects being promoted as first 
> class citizens
>   • Something else?
> Anyway, I am not sure about taking the next LTS as 3.0. Tables to divs story 
> is likely to be a problem for users due to regressions in various in-house 
> and not popular plugins which have not been fixed yet. Thanks to Tim, 
> Raihaan, Felix and many other contributors for the cleanup, but I doubt it 
> will be as smooth as Jenkins 1->2 upgrade for the users. 
> 
> Best regards,
> Oleg
> 
> P.S: If we do a major release, it would be awesome to get the terminology 
> cleanup finished at least for the Jenkins core and major plugins. Taking our 
> announcements this summer, this is not the topic we should roll over to 
> Jenkins 3.
> 
> 
> On Monday, January 25, 2021 at 6:53:59 PM UTC+1 msi...@cloudbees.com wrote:
> That's a good point. I still see people who don't know about pipelines 
> even though they've been around since Jenkins 2.0 IIRC. The updated UI 
> is also less well known. 
> 
> On Fri, Jan 22, 2021 at 9:23 PM Ming Tang  wrote: 
> > 
> > I think the release of Jenkins 3.x is very urgent. Let me put forward 
> > another very important reason: companies and users are abandoning Jenkins. 
> > Jenkins 2.x has a history of 5 years. In the past 5 years, Jenkins 2.x has 
> > many major features and incompatible modifications. The obsolescence, 
> > update, and requirements for higher versions of Jenkins core require 
> > constant upgrading of Jenkins and modification of the configuration. This 
> > is in the view of the end user (administrator) of Jenkins, but it is a toss 
> > in the view of the leader. Small versions usually mean small changes. For 
> > the leaders of Jenkins administrators, Jenkins 2.x is something that hasn't 
> > changed a lot for many years, but it requires labor-intensive maintenance 
> > and repeated exploration. The minor version upgrade hides the value of the 
> > new version of Jenkins! News organizations do not pay attention to minor 
> > version updates, and the leadership does not care about minor version 
> > updates. Only the Jenkins administrator knows what Jenkins has updated! 
> > Enterprises and users have begun to consider abandoning Jenkins! ! We need 
> > to let the outside know that Jenkins is undergoing major changes, not that 
> > it has not released a major version for 5 years. 
> > 
> > 在2020年12月3日星期四 UTC+8 上午2:02:20 写道： 
> >> 
> >> Inte

Re: Jenkins 3.x

[fque...@cloudbees.com]

I would be 100% behind a change to Jenkins 3 if we do an actual major 
release. For example, I would just nuke the current navigation system. I 
think one major pain point is the lack of sane separation of global 
navigation, local navigation and contextual actions. Redoing the whole 
sidebar would affect many plugins, but it's the sort of change I'd expect 
from a v3.

On Tuesday, January 26, 2021 at 12:25:58 PM UTC+1 Oleg Nenashev wrote:

> Marketing releases are indeed something we could consider. The next LTS 
> baseline selection starts this week, with ETA in early April. This release 
> will include a number of serious changes, and generally 3.0 might be 
> justified from the technical point of view. At the same time, it IMHO 
> requires a more fundamental change in Jenkins itself and its usage 
> paradigm. For example, in Jenkins 2 we were mostly promoting Jenkins 
> Pipeline and a few other related features, not the plugin unbundling as a 
> breaking change. If the whole point is about marketing, we need to prepare 
> well and to coordinate the rollout with CDF and key vendors so that we have 
> a big marketing push.
>
> We do not have a fresh new massive story to share. At the same time there 
> could be a few changes to highlight:
>
>- Adoption of Configuration-as-Code as a recommended way to manage 
>Jenkins.
>- Making emphasis on Jenkins-in-the-cloud applications and packaging, 
>with making Docker/Helm/etc. and downstream projects being promoted as 
>first class citizens
>- Something else?
>
> Anyway, I am not sure about taking the next LTS as 3.0. Tables to divs 
> story is likely to be a problem for users due to regressions in various 
> in-house and not popular plugins which have not been fixed yet. Thanks to 
> Tim, Raihaan, Felix and many other contributors for the cleanup, but I 
> doubt it will be as smooth as Jenkins 1->2 upgrade for the users. 
>
> Best regards,
> Oleg
>
> P.S: If we do a major release, it would be awesome to get the terminology 
> cleanup finished at least for the Jenkins core and major plugins. Taking 
> our announcements this summer, this is not the topic we should roll over to 
> Jenkins 3.
>
>
> On Monday, January 25, 2021 at 6:53:59 PM UTC+1 msi...@cloudbees.com 
> wrote:
>
>> That's a good point. I still see people who don't know about pipelines 
>> even though they've been around since Jenkins 2.0 IIRC. The updated UI 
>> is also less well known. 
>>
>> On Fri, Jan 22, 2021 at 9:23 PM Ming Tang  wrote: 
>> > 
>> > I think the release of Jenkins 3.x is very urgent. Let me put forward 
>> another very important reason: companies and users are abandoning Jenkins. 
>> Jenkins 2.x has a history of 5 years. In the past 5 years, Jenkins 2.x has 
>> many major features and incompatible modifications. The obsolescence, 
>> update, and requirements for higher versions of Jenkins core require 
>> constant upgrading of Jenkins and modification of the configuration. This 
>> is in the view of the end user (administrator) of Jenkins, but it is a toss 
>> in the view of the leader. Small versions usually mean small changes. For 
>> the leaders of Jenkins administrators, Jenkins 2.x is something that hasn't 
>> changed a lot for many years, but it requires labor-intensive maintenance 
>> and repeated exploration. The minor version upgrade hides the value of the 
>> new version of Jenkins! News organizations do not pay attention to minor 
>> version updates, and the leadership does not care about minor version 
>> updates. Only the Jenkins administrator knows what Jenkins has updated! 
>> Enterprises and users have begun to consider abandoning Jenkins! ! We need 
>> to let the outside know that Jenkins is undergoing major changes, not that 
>> it has not released a major version for 5 years. 
>> > 
>> > 在2020年12月3日星期四 UTC+8 上午2:02:20 写道： 
>> >> 
>> >> Interesting, first I had seen Revapi. Would be worth checking whether 
>> >> it can replace japicmp in `jenkinsci/jenkins`, which I introduced as 
>> >> part of JEP-227 but had to patch in order to properly handle 
>> >> POM/classpath changes (and unfortunately that patch remains 
>> >> unevaluated). 
>> > 
>> > -- 
>> > 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/9d0ad61c-e63e-47d5-9034-1b648e002198n

Re: Jenkins 3.x

[Oleg Nenashev]

Marketing releases are indeed something we could consider. The next LTS 
baseline selection starts this week, with ETA in early April. This release 
will include a number of serious changes, and generally 3.0 might be 
justified from the technical point of view. At the same time, it IMHO 
requires a more fundamental change in Jenkins itself and its usage 
paradigm. For example, in Jenkins 2 we were mostly promoting Jenkins 
Pipeline and a few other related features, not the plugin unbundling as a 
breaking change. If the whole point is about marketing, we need to prepare 
well and to coordinate the rollout with CDF and key vendors so that we have 
a big marketing push.

We do not have a fresh new massive story to share. At the same time there 
could be a few changes to highlight:

   - Adoption of Configuration-as-Code as a recommended way to manage 
   Jenkins.
   - Making emphasis on Jenkins-in-the-cloud applications and packaging, 
   with making Docker/Helm/etc. and downstream projects being promoted as 
   first class citizens
   - Something else?

Anyway, I am not sure about taking the next LTS as 3.0. Tables to divs 
story is likely to be a problem for users due to regressions in various 
in-house and not popular plugins which have not been fixed yet. Thanks to 
Tim, Raihaan, Felix and many other contributors for the cleanup, but I 
doubt it will be as smooth as Jenkins 1->2 upgrade for the users. 

Best regards,
Oleg

P.S: If we do a major release, it would be awesome to get the terminology 
cleanup finished at least for the Jenkins core and major plugins. Taking 
our announcements this summer, this is not the topic we should roll over to 
Jenkins 3.


On Monday, January 25, 2021 at 6:53:59 PM UTC+1 msi...@cloudbees.com wrote:

> That's a good point. I still see people who don't know about pipelines
> even though they've been around since Jenkins 2.0 IIRC. The updated UI
> is also less well known.
>
> On Fri, Jan 22, 2021 at 9:23 PM Ming Tang  wrote:
> >
> > I think the release of Jenkins 3.x is very urgent. Let me put forward 
> another very important reason: companies and users are abandoning Jenkins. 
> Jenkins 2.x has a history of 5 years. In the past 5 years, Jenkins 2.x has 
> many major features and incompatible modifications. The obsolescence, 
> update, and requirements for higher versions of Jenkins core require 
> constant upgrading of Jenkins and modification of the configuration. This 
> is in the view of the end user (administrator) of Jenkins, but it is a toss 
> in the view of the leader. Small versions usually mean small changes. For 
> the leaders of Jenkins administrators, Jenkins 2.x is something that hasn't 
> changed a lot for many years, but it requires labor-intensive maintenance 
> and repeated exploration. The minor version upgrade hides the value of the 
> new version of Jenkins! News organizations do not pay attention to minor 
> version updates, and the leadership does not care about minor version 
> updates. Only the Jenkins administrator knows what Jenkins has updated! 
> Enterprises and users have begun to consider abandoning Jenkins! ! We need 
> to let the outside know that Jenkins is undergoing major changes, not that 
> it has not released a major version for 5 years.
> >
> > 在2020年12月3日星期四 UTC+8 上午2:02:20 写道：
> >>
> >> Interesting, first I had seen Revapi. Would be worth checking whether
> >> it can replace japicmp in `jenkinsci/jenkins`, which I introduced as
> >> part of JEP-227 but had to patch in order to properly handle
> >> POM/classpath changes (and unfortunately that patch remains
> >> unevaluated).
> >
> > --
> > 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/9d0ad61c-e63e-47d5-9034-1b648e002198n%40googlegroups.com
> .
>
>
>
> -- 
> Matt Sicker
> Senior Software Engineer, CloudBees
>

-- 
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/4d5673c0-a69d-489e-a7fe-5a8545ddfccen%40googlegroups.com.

Re: Jenkins 3.x

[Matt Sicker]

That's a good point. I still see people who don't know about pipelines
even though they've been around since Jenkins 2.0 IIRC. The updated UI
is also less well known.

On Fri, Jan 22, 2021 at 9:23 PM Ming Tang  wrote:
>
> I think the release of Jenkins 3.x is very urgent. Let me put forward another 
> very important reason: companies and users are abandoning Jenkins. Jenkins 
> 2.x has a history of 5 years. In the past 5 years, Jenkins 2.x has many major 
> features and incompatible modifications. The obsolescence, update, and 
> requirements for higher versions of Jenkins core require constant upgrading 
> of Jenkins and modification of the configuration. This is in the view of the 
> end user (administrator) of Jenkins, but it is a toss in the view of the 
> leader. Small versions usually mean small changes. For the leaders of Jenkins 
> administrators, Jenkins 2.x is something that hasn't changed a lot for many 
> years, but it requires labor-intensive maintenance and repeated exploration. 
> The minor version upgrade hides the value of the new version of Jenkins! News 
> organizations do not pay attention to minor version updates, and the 
> leadership does not care about minor version updates. Only the Jenkins 
> administrator knows what Jenkins has updated! Enterprises and users have 
> begun to consider abandoning Jenkins! ! We need to let the outside know that 
> Jenkins is undergoing major changes, not that it has not released a major 
> version for 5 years.
>
> 在2020年12月3日星期四 UTC+8 上午2:02:20 写道：
>>
>> Interesting, first I had seen Revapi. Would be worth checking whether
>> it can replace japicmp in `jenkinsci/jenkins`, which I introduced as
>> part of JEP-227 but had to patch in order to properly handle
>> POM/classpath changes (and unfortunately that patch remains
>> unevaluated).
>
> --
> 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/9d0ad61c-e63e-47d5-9034-1b648e002198n%40googlegroups.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

-- 
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/CAEot4oyMa0SvOBBVSOpiL0Jpkk%2B7%2BC4JtqijiYxAvZSM1TygRw%40mail.gmail.com.

Re: Jenkins 3.x

[Ming Tang]

I think the release of Jenkins 3.x is very urgent. Let me put forward 
another very important reason: companies and users are abandoning 
Jenkins. Jenkins 2.x has a history of 5 years. In the past 5 years, Jenkins 
2.x has many major features and incompatible modifications. The 
obsolescence, update, and requirements for higher versions of Jenkins core 
require constant upgrading of Jenkins and modification of the 
configuration. This is in the view of the end user (administrator) of 
Jenkins, but it is a toss in the view of the leader. Small versions usually 
mean small changes. For the leaders of Jenkins administrators, Jenkins 2.x 
is something that hasn't changed a lot for many years, but it requires 
labor-intensive maintenance and repeated exploration. The minor version 
upgrade hides the value of the new version of Jenkins! News organizations 
do not pay attention to minor version updates, and the leadership does not 
care about minor version updates. Only the Jenkins administrator knows what 
Jenkins has updated! Enterprises and users have begun to consider 
abandoning Jenkins! ! We need to let the outside know that Jenkins is 
undergoing major changes, not that it has not released a major version for 
5 years.

在2020年12月3日星期四 UTC+8 上午2:02:20 写道：

> Interesting, first I had seen Revapi. Would be worth checking whether
> it can replace japicmp in `jenkinsci/jenkins`, which I introduced as
> part of JEP-227 but had to patch in order to properly handle
> POM/classpath changes (and unfortunately that patch remains
> unevaluated).
>

-- 
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/9d0ad61c-e63e-47d5-9034-1b648e002198n%40googlegroups.com.

Re: Jenkins 3.x

[Jesse Glick]

Interesting, first I had seen Revapi. Would be worth checking whether
it can replace japicmp in `jenkinsci/jenkins`, which I introduced as
part of JEP-227 but had to patch in order to properly handle
POM/classpath changes (and unfortunately that patch remains
unevaluated).

-- 
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/CANfRfr32CDfKyrxWPebg0%3DHoFt8Z%3DU437zfGnj-bPN-nO2bszw%40mail.gmail.com.

Re: Jenkins 3.x

[Matt Sicker]

Revapi is another great tool; we use it in Log4j2 nowadays after a
couple releases accidentally introduced minor binary compatibility
issues (but source compatible) in the logging API.

On Tue, Dec 1, 2020 at 7:15 AM Ullrich Hafner  wrote:
>
>
> Am 30.11.2020 um 22:51 schrieb Matt Sicker :
>
> I think Jesse has articulated my own feelings fairly well here. I will
> note that OSGi has some useful tooling [1] and semantics related to
> semantic versioning, generic Java plugins/modules/components, and some
> other well-explored areas related to compatibility which our own
> plugin ClassLoader only scratches the surface of.
>
> [1]: https://bnd.bndtools.org/commands/baseline.html
> https://bnd.bndtools.org/commands/diff.html
>
>
> I’m using https://revapi.org/l in my plugins to detect incompatible API 
> changes before a release. It seems to work quite similar and has support for 
> Jenkins JPI files now. The included maven plugin warns me if I try to remove 
> a method that actually might be used by a depending plugin.
>
> On Mon, Nov 30, 2020 at 3:45 PM Jesse Glick  wrote:
>
>
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0JZtW1x17eeUSVQzfAJgck08jVnfZ0%3DN4reZZ7RYx6fA%40mail.gmail.com.
>
>
>
>
> --
> Matt Sicker
> Senior Software Engineer, CloudBees
>
> --
> 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/CAEot4oz-kiQLAUrU3RQYr3en%2B%3DCAKsA1wOpwpHbkGk04sCq3tA%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 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/96F88098-40ED-4002-869B-2842D5E26746%40gmail.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

-- 
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/CAEot4oztA9bv%3DUfXibXcZr-zCEjMWEC6FuutdCWSa3gABfo%2BdA%40mail.gmail.com.

Re: Jenkins 3.x

[Ullrich Hafner]

> Am 30.11.2020 um 22:51 schrieb Matt Sicker :
> 
> I think Jesse has articulated my own feelings fairly well here. I will
> note that OSGi has some useful tooling [1] and semantics related to
> semantic versioning, generic Java plugins/modules/components, and some
> other well-explored areas related to compatibility which our own
> plugin ClassLoader only scratches the surface of.
> 
> [1]: https://bnd.bndtools.org/commands/baseline.html
> https://bnd.bndtools.org/commands/diff.html
> 

I’m using https://revapi.org/l  in my plugins to detect 
incompatible API changes before a release. It seems to work quite similar and 
has support for Jenkins JPI files now. The included maven plugin warns me if I 
try to remove a method that actually might be used by a depending plugin. 

> On Mon, Nov 30, 2020 at 3:45 PM Jesse Glick  wrote:
>> 
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0JZtW1x17eeUSVQzfAJgck08jVnfZ0%3DN4reZZ7RYx6fA%40mail.gmail.com.
> 
> 
> 
> -- 
> Matt Sicker
> Senior Software Engineer, CloudBees
> 
> -- 
> 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/CAEot4oz-kiQLAUrU3RQYr3en%2B%3DCAKsA1wOpwpHbkGk04sCq3tA%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 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/96F88098-40ED-4002-869B-2842D5E26746%40gmail.com.

Re: Jenkins 3.x

[Slide]

I would also prefer some date based release numbering a la IntelliJ rather
than semantic versioning, for all the reasons that Jesse has spelled out.

On Mon, Nov 30, 2020 at 2:45 PM Jesse Glick  wrote:

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


-- 
Website: http://earl-of-code.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/CAPiUgVfmdhs-_yOpiWAwsgeocz_Mu6U1xD8xuq0m1m-7XBEO8g%40mail.gmail.com.

Re: Jenkins 3.x

[Jesse Glick]

On Mon, Nov 30, 2020 at 4:52 PM Matt Sicker  wrote:
> tooling […] related to semantic versioning

Note that we have, for example,

https://ci.jenkins.io/job/Core/job/jenkins/job/master/API_20compatibility/

Interesting so far as it goes: will tell you whether _plugins_
updating to this version _might_ experience `LinkageError`’s (usually,
though not always, correlated to compilation errors).

-- 
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/CANfRfr3Ajz%3D-A_7WXcJxbLjrBQHy6AEq2to4LD7g%2B8%2BKvzeGFQ%40mail.gmail.com.

Re: Jenkins 3.x

[Matt Sicker]

I think Jesse has articulated my own feelings fairly well here. I will
note that OSGi has some useful tooling [1] and semantics related to
semantic versioning, generic Java plugins/modules/components, and some
other well-explored areas related to compatibility which our own
plugin ClassLoader only scratches the surface of.

[1]: https://bnd.bndtools.org/commands/baseline.html
https://bnd.bndtools.org/commands/diff.html

On Mon, Nov 30, 2020 at 3:45 PM Jesse Glick  wrote:
>
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0JZtW1x17eeUSVQzfAJgck08jVnfZ0%3DN4reZZ7RYx6fA%40mail.gmail.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

-- 
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/CAEot4oz-kiQLAUrU3RQYr3en%2B%3DCAKsA1wOpwpHbkGk04sCq3tA%40mail.gmail.com.

Re: Jenkins 3.x

[Jesse Glick]

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

Re: Jenkins 3.x

[Tim Van Holder]

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 .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  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, 
> 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 

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: 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: 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 upda

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
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>>> You rece

Re: Jenkins 3.x

[Beryl Snyder]

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-dev+unsubscr...@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
>> <https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com?utm_medium=email_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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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_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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAKDA9fRDGBe8KQJHSzKy-cHfzJbsgZozMB76YvLKZhNnGZtmow%40mail.gmail.com.

Re: Jenkins 3.x

[Baptiste Mathus]

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-dev+unsubscr...@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
> <https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com?utm_medium=email_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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com.

Re: Jenkins 3.x

[Oleg Nenashev]

Hi all,

I am also open to discuss the Jenkins 3.x release, as well as any changes 
in the versioning policy which would be helpful to Jenkins adopters. I am 
not a big fan of semver due to the same reasons as Daniel noted, but it is 
definitely one of the options on the table. My only ask here is to not 
hurry with the decisions. We will have a newly elected Release Officer on 
Dec 03, and I would wait until this happens before we do final decisions.

The next LTS cycle definitely looks to be a good opportunity for a 3.0 
release from the technical standpoint. There is a lot of breaking changes 
that justify it. It would be great to deliver even more changes, but I 
doubt we will be able to have coordinated effort for that before the next 
LTS cycle (holidays and so on). So we can ship what we have.

On a separate note, Jenkins X 3.0 is also tentatively scheduled to early 
next year. It may lead to some confusion if Jenkins and Jenkins X releases 
happen within a short timeframe.

Best regards,
Oleg Nenshev





On Thursday, November 26, 2020 at 3:53:06 PM UTC+1 db...@cloudbees.com 
wrote:

> On Thu, Nov 26, 2020 at 1:53 PM Manuel Ramón León Jiménez <
> manuelramon...@gmail.com> wrote:
>
>>
>> Anyway, I would like, when the time comes, to introduce semantic 
>> versioning <https://semver.org/#why-use-semantic-versioning>, adding a 
>> third number to the version and using them according to this way of 
>> versioning. In the future we can extend it to plugins and add some features 
>> in core to support / check / leverage this.
>>
>
> We barely keep up with basic maintenance, and we're bound to get this 
> wrong on a fairly regular basis given how we merge and release. Unless 
> you're proposing to completely overhaul all of this, I'd say it's not worth 
> the effort to then have people complaining whenever we mess up. 
>

-- 
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/5b0886f6-8192-49c3-8190-d8e4d81c18bbn%40googlegroups.com.

Re: Jenkins 3.x

[Daniel Beck]

On Thu, Nov 26, 2020 at 1:53 PM Manuel Ramón León Jiménez <
manuelramonleonjime...@gmail.com> wrote:

>
> Anyway, I would like, when the time comes, to introduce semantic
> versioning , adding a
> third number to the version and using them according to this way of
> versioning. In the future we can extend it to plugins and add some features
> in core to support / check / leverage this.
>

We barely keep up with basic maintenance, and we're bound to get this wrong
on a fairly regular basis given how we merge and release. Unless you're
proposing to completely overhaul all of this, I'd say it's not worth the
effort to then have people complaining whenever we mess up.

-- 
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/CAMo7Pt%2BDW5FPLKrfJQQ9DwNfLj8_xRmenJ36xPK%3DUx%2BNBWvDjg%40mail.gmail.com.

Re: Jenkins 3.x

['Olblak' via Jenkins Developers]

> Aren’t we are a little bit late for it, since these changes are already part 
> of 2.x? Additionally, wouldn’t it be helpful if we have some groundbreaking 
> user visible changes in 3.x as well (as we had in 2.x)? 
I would say it's still fine as long as those changes aren't in the LTS

> 
> Anyway, I would like, when the time comes, to introduce semantic versioning 
> <https://semver.org/#why-use-semantic-versioning>, adding a third number to 
> the version and using them according to this way of versioning. In the future 
> we can extend it to plugins and add some features in core to support / check 
> / leverage this.
Isn't it already the case for Lts releases? 
Do we often have weekly releases that only contain bugfixes?


On Thu, Nov 26, 2020, at 12:53 PM, Manuel Ramón León Jiménez wrote:
> Hi.
> 
> I don't have a strong opinion although I tend to think more like Ulrich. 
> Maybe the UI revamp would be a good inflection point, in addition to these 
> breaking changes..
> 
> Anyway, I would like, when the time comes, to introduce semantic versioning 
> <https://semver.org/#why-use-semantic-versioning>, adding a third number to 
> the version and using them according to this way of versioning. In the future 
> we can extend it to plugins and add some features in core to support / check 
> / leverage this.
> 
> Thanks!
> 
> On Thu, Nov 26, 2020 at 12:56 PM Ullrich Hafner  
> wrote:
>> Aren’t we are a little bit late for it, since these changes are already part 
>> of 2.x? Additionally, wouldn’t it be helpful if we have some groundbreaking 
>> user visible changes in 3.x as well (as we had in 2.x)? 
>> 
>>> Am 26.11.2020 um 09:47 schrieb Arnaud Héritier :
>>> 
>>> I think it's a good idea.
>>> In the same spirit than 1.x -> 2.x (We justify the bump by the risk to 
>>> impact a large number of plugins)
>>> 
>>> 
>>> 
>>> On Thu, Nov 26, 2020 at 9:29 AM Ivan Fernandez Calvo 
>>>  wrote:
>>>> +1000 to considered those changes as a major change
>>>> 
>>>> El miércoles, 25 de noviembre de 2020 a las 17:37:21 UTC+1, James Nord 
>>>> escribió:
>>>>> 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-dev+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com?utm_medium=email_source=footer>.
>>> 
>>> 
>>> -- 
>>> Arnaud Héritier
>>> Twitter/Skype : aheritier
>>> 
>>> -- 
>>> 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/CAFNCU-8n8qzP0NZrAazGkg-U7Anf2Mrz1ZCgbUoqiJjz4LeWCA%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8n8qzP0NZrAazGkg-U7Anf2Mrz1ZCgbUoqiJjz4LeWCA%40mail.gmail.com?utm_medium=email_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 

Re: Jenkins 3.x

[Ullrich Hafner]

Aren’t we are a little bit late for it, since these changes are already part of 
2.x? Additionally, wouldn’t it be helpful if we have some groundbreaking user 
visible changes in 3.x as well (as we had in 2.x)? 

> Am 26.11.2020 um 09:47 schrieb Arnaud Héritier :
> 
> I think it's a good idea.
> In the same spirit than 1.x -> 2.x (We justify the bump by the risk to impact 
> a large number of plugins)
> 
> 
> 
> On Thu, Nov 26, 2020 at 9:29 AM Ivan Fernandez Calvo  <mailto:kuisathave...@gmail.com>> wrote:
> +1000 to considered those changes as a major change
> 
> El miércoles, 25 de noviembre de 2020 a las 17:37:21 UTC+1, James Nord 
> escribió:
> 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-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com?utm_medium=email_source=footer>.
> 
> 
> -- 
> Arnaud Héritier
> Twitter/Skype : aheritier
> 
> -- 
> 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 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8n8qzP0NZrAazGkg-U7Anf2Mrz1ZCgbUoqiJjz4LeWCA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8n8qzP0NZrAazGkg-U7Anf2Mrz1ZCgbUoqiJjz4LeWCA%40mail.gmail.com?utm_medium=email_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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7E4AA979-7FBB-4712-BCE6-B24C28840F50%40gmail.com.

Re: Jenkins 3.x

[Arnaud Héritier]

I think it's a good idea.
In the same spirit than 1.x -> 2.x (We justify the bump by the risk to
impact a large number of plugins)



On Thu, Nov 26, 2020 at 9:29 AM Ivan Fernandez Calvo <
kuisathave...@gmail.com> wrote:

> +1000 to considered those changes as a major change
>
> El miércoles, 25 de noviembre de 2020 a las 17:37:21 UTC+1, James Nord
> escribió:
>
>> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Arnaud Héritier
Twitter/Skype : aheritier

-- 
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/CAFNCU-8n8qzP0NZrAazGkg-U7Anf2Mrz1ZCgbUoqiJjz4LeWCA%40mail.gmail.com.

Re: Jenkins 3.x

[Ivan Fernandez Calvo]

+1000 to considered those changes as a major change

El miércoles, 25 de noviembre de 2020 a las 17:37:21 UTC+1, James Nord 
escribió:

> 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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com.

Jenkins 3.x

[James Nord]

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-dev+unsubscr...@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.