Re: Branches

Thu, 05 Mar 2026 01:45:20 -0800

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]























					Reply via email to