Great thread to start, Richard! My request to everyone who responds: please be clear on where you’re willing to spend your time. If we get a lot of +1s for an option, but not enough people actually volunteering to do the work, it really isn’t an option.
Here’s my perspective on each branch: - TomEE 9. We need to keep that CVE patched and actively released. If we don’t then people on TomEE 8 looking to migrate away won’t actually have a safe place to migrate to. I’d be willing to put contribution time into CVE patches and doing or reviewing releases on TomEE 9 till TomEE 10 is released + 6 months so people have time to migrate from 9 to 10. We would either need to upgrade to Tomcat 10.1 to make this work or volunteer time in Tomcat to maintaining 10. - TomEE 8. I’d be willing to review patches, help with release releases, etc for this year, so people have time to migrate. As it will negatively impact our TomEE 10 work and people will mostly likely not take advantage unless forced, I’d want to have a clear end-of-life date that we set now. I think Dec 31st, 2023 is a good date. That date would be communicated as best effort — if a dependency like say CXF stops maintaining the version we need, the actual end of life date for TomEE 8 would be shorter. This would all have to be documented and visible when people download TomEE 8. I wouldn’t be willing to put time into TomEE 8 open-ended, without an agreed end-of-life date. Not as critical, but we might also be smart to do just one release a quarter or something to minimize impact. - TomEE 7 & TomEE 1.7. These are already effectively discontinued. I think we should actually label them discontinued. I definitely would not be willing to review patches or release binaries for those branches. # General End-of-life policy thoughts I had in the past leaned against officially calling a branch discontinued, but I think I’m swayed the other way on that. Nobody wants to do the javax-to-jakarta transition and given the opportunity to put it off, everyone will. In my experience, people don’t like to upgrade even when there are no breaking changes — the fear of one being hidden in there somewhere is enough to stop a lot of people. In absence of a clear “this is going away” date, a lot of people will either hold off upgrading or not be able to get the internal support for doing an upgrade. If I had to take a stab at a default end-of-life policy, I’d probably recommend something like this: - We maintain the latest stable (final) release branch indefinitely while the next branch is in development (non-final) - When the development branch becomes final and becomes the new latest stable, we immediately announce the previous latest stable will be end-of-life in 6 months so people know to use the time to migrate. - Any end-of-life date can be extended (e.g. TomEE 8) if someone shows up willing to do the work and commits to a new end-of-life date (which can again be extended if there are volunteers) - If we cannot patch all the CVEs in a branch, we likely should have a policy against releasing it and that may shorten the end-of-life date Thoughts on all the above? -David > On Feb 7, 2023, at 10:59 AM, Richard Zowalla <r...@apache.org> wrote: > > Hi all, > > I wanted to bring this thing to the list, which appeared in a slack > chat today. > > Back in October 2021 we had a discussion on how we want to handle our > three active branches (8.x, 9.x and main/10.x) in terms of maintainance > [1]. We already agreed in another thread, that we are not activley > maintain 7.0.x or 7.1.x (but are open for contributions) anymore. > > Now, we have a 9.0.0 released, which passes the TCK (which by itself is > really a great achievement!) and we are dived into the EE10 work to > have the momentum. > > However, we missed to find consensus on the different proposals and > arguments and didn't make a decision or a vote back than. Currently, I > am seeing, that we are doing work on three different branches and > porting things back and forth ;-) - the situation is a bit agile (lol) > and it is really difficult to keep track (even if it only affects > common dependency updates). > > At the moment, we have: > > - 8.x (EE8) > - 9.x (EE9) > - 10.x/main (EE10) > > Keeping up with three diverging code bases is challenging ;-) > > In addition, the situation is complicated by the fact, that the Tomcat > project decided to EOL their 10.0.x line, which is targeting EE9 and > won't get any fixes in the future. > > I think, that we should discuss our prorities in maintaining the > different branches, ie. how much "love" (or energy) we want to give > each branch (if someone steps up and keeps up porting changes, I > wouldn't be against it). > > Personally, I think, that we should keep up our efforts in maintaining > 8.x (as it is the last javax version and industry will need some more > adoption time before moving to jakarta), ie fixing build improvements, > bug & cves but put the vast majority of our energy into the EE10 work > (+ related projects). I don't think, that we have the energy to > backporting a lot of things to the 9.x branch (aside from CVE fixes, > which might be difficult to the eoling of some libs)) though - but > again: If someone steps up and has the energy to do that, I won't > object :-) > > Any thoughts or ideas on a strategy? > > Gruß > Richard > > > > > > > [1] https://lists.apache.org/thread/z953f2th5kqc3brjvcjmjwwo93hcd970 >
