Any other thoughts?
-David > On Feb 8, 2023, at 12:07 PM, David Blevins <david.blev...@gmail.com> wrote: > > 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 >> >
