Jenkins 3.x

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Jenkins 3.x

James Nord-2
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

kuisathaverat
+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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8n8qzP0NZrAazGkg-U7Anf2Mrz1ZCgbUoqiJjz4LeWCA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Ulli 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 <[hidden email]>:

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


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8n8qzP0NZrAazGkg-U7Anf2Mrz1ZCgbUoqiJjz4LeWCA%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7E4AA979-7FBB-4712-BCE6-B24C28840F50%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Manuel Ramón León Jiménez-2
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, 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 <[hidden email]> 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 <[hidden email]>:

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


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8n8qzP0NZrAazGkg-U7Anf2Mrz1ZCgbUoqiJjz4LeWCA%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7E4AA979-7FBB-4712-BCE6-B24C28840F50%40gmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CADN1OJ25c1K%2BrRbX9zf3oKBdrbsU3sSBYOiGLVA4pgW18QKrNw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Olblak-2
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, 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, 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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 [hidden email].


--
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 [hidden email].


--
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 [hidden email].


--
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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/03040c1c-4520-4d7c-b188-990015dbb4c0%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Daniel Beck-2
In reply to this post by Manuel Ramón León Jiménez-2


On Thu, Nov 26, 2020 at 1:53 PM Manuel Ramón León Jiménez <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BDW5FPLKrfJQQ9DwNfLj8_xRmenJ36xPK%3DUx%2BNBWvDjg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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 [hidden email] wrote:
On Thu, Nov 26, 2020 at 1:53 PM Manuel Ramón León Jiménez <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5b0886f6-8192-49c3-8190-d8e4d81c18bbn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Baptiste MATHUS
In reply to this post by James Nord-2
TBH, I'd just embrace the more and more common yyyy-mm-dd ish pattern of releases.

It would kind of make this clearer to outsiders that the version numbers of Jenkins are close to nothing related to stability but more a very regularly recurring release pattern.

_Maybe_ I'd then agree with you for some new/adjusted version scheme *for LTSes*, but not worth doing this for weeklies IMO.

It's my very personal opinion, fwiw.

-- Baptiste

Le mer. 25 nov. 2020 à 17:37, James Nord <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
TBH, I'd just embrace the more and more common yyyy-mm-dd ish pattern of releases.

It would kind of make this clearer to outsiders that the version numbers of Jenkins are close to nothing related to stability but more a very regularly recurring release pattern.

_Maybe_ I'd then agree with you for some new/adjusted version scheme *for LTSes*, but not worth doing this for weeklies IMO.

It's my very personal opinion, fwiw.

-- Baptiste

Le mer. 25 nov. 2020 à 17:37, James Nord <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKDA9fRDGBe8KQJHSzKy-cHfzJbsgZozMB76YvLKZhNnGZtmow%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Gavin Mogan
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 <[hidden email]> 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 <[hidden email]> wrote:
TBH, I'd just embrace the more and more common yyyy-mm-dd ish pattern of releases.

It would kind of make this clearer to outsiders that the version numbers of Jenkins are close to nothing related to stability but more a very regularly recurring release pattern.

_Maybe_ I'd then agree with you for some new/adjusted version scheme *for LTSes*, but not worth doing this for weeklies IMO.

It's my very personal opinion, fwiw.

-- Baptiste

Le mer. 25 nov. 2020 à 17:37, James Nord <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKDA9fRDGBe8KQJHSzKy-cHfzJbsgZozMB76YvLKZhNnGZtmow%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusttK8%2Btqh1OS1MSa0tf1qn2k%2BkMbefM7n9FE1DfbDq6A%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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 [hidden email] 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 <[hidden email]> 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 <[hidden email]> wrote:
TBH, I'd just embrace the more and more common yyyy-mm-dd ish pattern of releases.

It would kind of make this clearer to outsiders that the version numbers of Jenkins are close to nothing related to stability but more a very regularly recurring release pattern.

_Maybe_ I'd then agree with you for some new/adjusted version scheme *for LTSes*, but not worth doing this for weeklies IMO.

It's my very personal opinion, fwiw.

-- Baptiste

Le mer. 25 nov. 2020 à 17:37, James Nord <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e84b4c07-5da4-44c3-9de1-d89e36a82ca9n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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 [hidden email] 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 <[hidden email]> 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 <[hidden email]> wrote:
TBH, I'd just embrace the more and more common yyyy-mm-dd ish pattern of releases.

It would kind of make this clearer to outsiders that the version numbers of Jenkins are close to nothing related to stability but more a very regularly recurring release pattern.

_Maybe_ I'd then agree with you for some new/adjusted version scheme *for LTSes*, but not worth doing this for weeklies IMO.

It's my very personal opinion, fwiw.

-- Baptiste

Le mer. 25 nov. 2020 à 17:37, James Nord <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/71c2a1b9-e1ce-4a74-a5ee-732cd217d6fbn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Ulli Hafner
In reply to this post by Gavin Mogan
>
> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/E40815F5-E8B5-4B4C-88D7-9CC8715403DA%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Felix Queiruga
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 [hidden email] 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/973dd22a-cc5b-4640-935c-f729ce6a2979n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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 [hidden email] 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 [hidden email] 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/341c82d4-1d1b-4886-a1c3-7e3b7ffa0c7an%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

teilo
>  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 YYYY.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 <[hidden email]> 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 [hidden email] 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 [hidden email] 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPzq3pfrqzQ3CL0dSeZ164TmCx1UytgOcKdbYq0%3DtQt1n%2BoJog%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Daniel Beck


> On 27. Nov 2020, at 18:26, James Nord <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/DF8247AA-3945-4720-8E73-D050C16383A9%40beckweb.net.
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bdc030e7-24c9-477c-a7ea-064e4e106421n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins 3.x

Richard Bywater-3
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, <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwfi%2BGxqS2WR-1AzpSLB3BJH2%3D7fmGLGMmZzfM-cfGj2qw%40mail.gmail.com.
12