My initial post was about branch re-organisation and not about which versions are going to be supported. I think these are two distinct things. I assume users don't care how we organise our work - none of them posted a message in this thread ;)
Users just need a clear information which versions they can safely use and as for me this is clear: - Struts 7.x is the current main line which will gain all the new features, security and bug fixes - Struts 6.x is in a support mode and users can only expect critical security fixes and minor bug fixes (especially if introduced in previous 6.x releases) Having said that, the current branch setup makes it hard to prepare a fast-track release of a prior release, why? Because the flow looks like this: - identify which version are affected - select which version should be fixed starting from the latest - sometimes the security fix is more an architectural change than just a code change so it won't be possible to prepare a new release for older versions, see the case with Struts 6.4.0 and S2-067 - for a new release use the latest tag of the identified versions (eg. STRUTS_6_4_0) as a starting point to apply the fix, this means create a release branch out of the tag - apply the fix, release a new version, tag it and publish - drop the branch at some point once Vote passed and adoption is progressing - repeat The current branch layout was my idea as I thought it will be easier this way, but the flow described above is more robust. I don't have to worry what changes are already included in a given struts-6-x-x branch, just use the tag, apply fix and done - users expect a new release not just a new branch. Cheers Łukasz czw., 5 mar 2026 o 10:45 Rene Gielen <[email protected]> napisał(a): > > Semver says minor number change must not break downward compatibility. > It may introduce tons of new and swap out any existing logic, as long as > the API stays compatible. For entities which have ITIL and the like in > place, this means full review with all bells and whistles and days or > weeks of updates being blocked. > > Patch number increases, in contrast, should guarantee to be real drop-in > replacements, only fixing the issues found and touching nothing else. > This is especially crucial to enable fast-track rollouts due to severe > security issues. > > Anyway, that's just my 0.02$. Feel free to go ahead with the simple > branch model. > > Nevertheless, we should consider having a super easy to find support > schedule (and maybe roadmap) to help people understand and make support > windows and EOL (and thus the need for rolling out breaking changes) > more predictable. What Lukasz said below is better not buried in an > user@ email thread :) > > - René > > Am 04.03.26 um 07:28 schrieb Kusal Kithul-Godage: > > Agreed with Łukasz here. > > > > If SemVer is followed closely, the effort in upgrading from say, 6.7.0 > > to 6.7.1, should be similar or the same as 6.7.0 to 6.9.1. > > > > One other consideration is that users might want to avoid the risk of > > being affected by new bugs when upgrading to a new minor release. > > However, we haven't shipped any such features in the 6.x line > > recently, and so I feel only supporting the latest 6.x minor is a > > reasonable stance to take. > > > > On 2026/03/03 06:09:38 Lukasz Lenart wrote: > >> pon., 2 mar 2026 o 17:12 Rene Gielen <[email protected]> napisał(a): > >>> Do we have a clearly documented support schedule now that were're on > >>> real semantic versioning? > >> Looks like we have it only here > >> https://struts.apache.org/announce-2022#a20220606 > >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199528107#VersionNotes6.0.0-Versionchange > >> > >>> I would expect to have a support branch for each not EOLed, thus > >>> supported, major / minor combination. I've always regarded this a best > >>> practice I follow, and most of the project I'm aware of. This also gives > >>> clear expectations for users, making clear which release lines are > >>> supposed to get at least bugfixes. > >> I think the current proposal is very simple, we support Struts 7.x and > >> Struts 6.x, while Struts 6.x will get only security fixes and bug > >> fixes identified in the previous releases of Struts 6 line. > >> > >>> Do we expect to release patches for 6.1? Rather not, do we? > >> No, I do not plan to support such old versions, especially there are > >> known vulnerabilities in Struts 6.7-6.0 > >> https://struts.apache.org/releases.html > >> > >>> What about 6.7 and 6.8? Sounds more legit to me, at least for an > >>> important security fix. > >> They are supported by upgrading to Struts 6.8.x and incoming 6.9.x. > >> Maybe we could have dedicated releases to address a security fix in > >> 6.7-6.8, but I assume the preferred way is to upgrade to the latest > >> 6.x version. The incoming 6.9.x release includes 21 fixes (mostly bug > >> fixes identified in the previous 6.x versions) > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WW%20AND%20fixVersion%20%3D%206.9.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > >> > >> Once released I would focus only on stabilizing the 6.9.x branch, > >> letting users know that this is probably the last 6.x release. The > >> first Struts 6 version has been released almost 4 years ago > >> https://cwiki.apache.org/confluence/display/WW/Version+Notes+6.0.0 > >> > >>> But even if we say only the last minor version in 6 is supposed to get > >>> updates, naming the only branch besides main "support/6.8.x" rather than > >>> "support/6.x" expresses our intentions more clearly. In addition, we're > >>> still able to have two or more supported branches within the same major > >>> line if this is anyhow required, without breaking our naming conventions > >>> and the expectations of our users. > >> I understand, but supporting many 6.x branches creates a burden in > >> setting up infra around them, Dependanbot, Sonar, Jenkins, even Github > >> actions must have a different set of JDK targets. Also Struts 6.x > >> depends on JDK8 which was EOLed in 2019. > >> > >> Optionally we can have main and support/6.x branches and keep > >> release/6.8.x, release/6.7.x and so on > >> > >> > >> Cheers > >> Łukasz > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > -- > René Gielen > https://about.me/rgielen > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
