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]
