Two cents on this based on our discussion on Friday. Agreed that a year based approach is the better long term solution, but I’d argue switching to 3.x is the better short term move. We need to agree what we’re doing this for - e.g. a marketing boost for the short term vs more sensible version numbers for the long term. I'd argue we'd benefit more from the short term boost than the long term, e.g. increasing/maintaining user base, increasing contributors for 2026/2027. On Monday, 2 February 2026 at 10:05:18 UTC [email protected] wrote:
> In that case, if we switch around July, should that release be 2026.0 (or > 2026.1, see above), or 2026.27, and why? > > > Personally I'd go with 2026.1 and start the first release of 2027 as > 2027.1 and counting upwards until 2028, repeat. > Even though we *could *make the minor version correlate with the week it > has been released in I don't think we should do that really: > > * first release of 2027 is likely not being shipped in the first week, so > we already would have a gap / deviation from the start > * if we re-release or have multiple releases within a week we would have > deviations > * if we skip a weekly release we would have gaps in our versions which I > always find confusing > > I'd just make it synonym for "it's the n-th release of a year" which would > always be correct rather than "it was released in week N, or maybe a little > before that". > > -- 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/d111a39b-0e19-46a0-b8e5-c10223d0ede2n%40googlegroups.com.
