Governance meeting Feb 23, 2022

[Mark Waite]

The Jenkins governance board meeting will start at 9:00 PM UTC today.  Agenda items include:

• News

  • Jenkins 2.336 released with several icon and image fixes (2.335 issues)

  • Jenkins LTS 2.332.1-rc ready to test

  • Jenkins LTS 2.332.1 scheduled to release March 9, 2022

• Press contact email alias - Gavin Mogan

  • Discourse trials

• Version number to yearly?

  • Starting in with 23.01 being the first week of the year 2023

  • Would make people assume semver less

  • Harder to skip/reissue/etc a release

• Version number to 3.x when we require Java 11 or newer? - Mark Waite

  • Sep 2022 or Jun 2022 LTS releases, a weekly 6-8 weeks before

• Highlights from the mailing lists and community forum

  • 
    

• EasyCLA status report - Oleg Nenashev

  • Ongoing

[Jesse Glick]

• Version number to yearly?

• • Starting in with 23.01 being the first week of the year 2023

• • Harder to skip/reissue/etc a release
    

Or format as a date, like 2022.02.23, so we can issue up to one release a day. Or drop MRP and use CD versions…

Version number to 3.x when we require Java 11 or newer?

Rather not, because this implies that the upgrade is incompatible for most users and a giant change in behavior, whereas it is just a newer version of a runtime dependency.

[Slide]

• 
  Version number to yearly?

  • Starting in with 23.01 being the first week of the year 2023

  • Harder to skip/reissue/etc a release
    

Or format as a date, like 2022.02.23, so we can issue up to one release a day. Or drop MRP and use CD versions…

Windows installers have issues with versions like this, there are limits on how high the major/minor/build version can go.

FileVersions and ProductVersions are unrelated. ProductVersion is shown in Add/Remove Programs ( Programs and Features ) and is mainly used during Major Upgrade scenarios to decide what should happen.

ProductVersion Property is defined as [0-255].[0-255].[0-65535] ( 8,8,16 signed bit respectively) File Version is defined as [0-65535].[0-65535].[0-65535].[0-65535] ( 16,16,16,16 signed bit... )

 

The product version is already mangled to support LTS releases, it might get confusing as to what version is installed if we have to mangle more.

[Gavin Mogan]

Technical limitations is why we talked about at a high level, and
looking to create a JEP first

> Or format as a date, like 2022.02.23, so we can issue up to one release a day. Or drop MRP and use CD versions…

how would lts work? 2022.02.23.1? I think that'll confuse a lot of
version parsers.

Maybe we should go IPV6 when that happens (cause 4 periods = IPv4
..okay I'll see myself out)

> ProductVersion Property is defined as [0-255].[0-255].[0-65535] ( 8,8,16 signed bit respectively) File Version is defined as [0-65535].[0-65535].[0-65535].[0-65535] ( 16,16,16,16 signed bit... )

22.03.01 would still work then, as would 22.03.01.1 since the .1
would be just fileversion? I don't know?

> --
> 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/CAPiUgVc1HtMoz32xGzaKix8Hh5Ce3SZzGy%3DGxJHbqy_tezEuzw%40mail.gmail.com.

[Jesse Glick]

On Wed, Feb 23, 2022 at 6:46 PM Slide <slide...@gmail.com> wrote:

Windows installers have issues with versions like this

Interesting. In general native packagings may have to process the version number to follow specific conventions or restrictions.

The product version is already mangled to support LTS releases, it might get confusing as to what version is installed if we have to mangle more.

Indeed a native package version ought to at least visually include the true (Maven) version.

[Mark Waite]

On Wednesday, February 23, 2022 at 3:42:50 PM UTC-7 Jesse Glick wrote:

Version number to 3.x when we require Java 11 or newer?

Rather not, because this implies that the upgrade is incompatible for most users and a giant change in behavior, whereas it is just a newer version of a runtime dependency.

Thanks for the insights.  I agree.  The change of major version risks that people expect dramatic changes in functionality and this is not dramatically changing functionality.

Someone also shared that my examples (JGit, Jetty) were libraries that needed to communicate breaking changes in their API's through a change of major number.  We're not making breaking changes in the API's as part of requiring Java 11 or newer, so it does not justify increasing the major number.

I'm pulling back from the idea of making the Jenkins version that requires Java 11 be a new major version.  I think we should stay with 2.x.

Mark Waite

[Daniel Beck]

On Thu, Feb 24, 2022 at 11:27 PM 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

> Or format as a date, like 2022.02.23, so we can issue up to one release a day. Or drop MRP and use CD versions…

how would lts work? 2022.02.23.1? I think that'll confuse a lot of
version parsers.

Re versions, please keep the current model of 2 section weeklies and 3 section LTS. I expect quite some stuff to break otherwise.

With that in mind, How about the second part just being a counter, roughly but not exactly corresponding to week-of-year?

23.1 is the first weekly release of 2023, followed by 23.2, 23.3, … , through 23.55 or so, and then 24.1.

LTS might be 23.8.x, then 23.20.x, 23.34.x, etc.

 

[Gavin Mogan]

> With that in mind, How about the second part just being a counter, roughly but not exactly corresponding to week-of-year?

Yea that's more or less what we talked about, 23.01 -> 23.99. 23.52
would be approximate end of year, but not absolutely end of the year.
The nice win is for when doing support with people, you don't have to
do drastic math to figure out how old something is, 22.30 is mid this
year, we don't need to know what week 30 is, so gives us wiggle room
to have re-releases and CI failures and stuff.

On Mon, Feb 28, 2022 at 3:53 PM 'Daniel Beck' via Jenkins Developers

> --
> 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/CAMo7PtKbTgZYH8BSy8-08USp_afn3_3hEcH4mQ_%3Dxea%3DAh7xrQ%40mail.gmail.com.