1. Where can I find the JEP for this, that explains pros, cons and motivation of (i.e. what does Jenkins want to achieve with) this change? 2. -1 for anything else than ISO-based dates, if any change is actually needed.
> I don't see the difference in marketing boost between 3.x and year based version. In both cases, the users will see a significant change to the version number and will evaluate the meaning of that significant change to the version number. +100 > Moving to 3.0 would indicate to me a new major release, regardless of knowing the current version number; whereas moving to 2027.1 I could assume is just a standard incremental change from 2026.x Fully agree, this change seems confusing to me, hence I'd like to learn more about the actual need/motivation. On Wednesday, 4 February 2026 at 18:57:14 UTC+1 Daniel Beck wrote: > > > > On 4. Feb 2026, at 00:34, 'Jesse Glick' via Jenkins Developers < > [email protected]> wrote: > > > > Call a trunk release 2026.04.20 and you can release on any day you > choose, not bound by a weekly schedule. If you cut a maintenance branch > from that, its releases would be 2026.04.20.1, 2026.04.20.2, etc. The next > “LTS” line (I would debate the accuracy of the “long-term” phrasing) would > be something like 2026.07.16.x. > > Lacking certainty over what the next version number is going to be and > adding an additional version segment both seem like changes requiring > rework around the actual releases (update-center, changelog generator, > etc.) for unclear benefits. Additionally it would prevent regression fix > re-releases the same day. Out of all the options discussed here, this looks > like the least desirable. > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/00ac1586-e37e-4978-99e2-6ffd88910e42n%40googlegroups.com.
