Hey David, Wanted to reply over the weekend but I think I forgot.
First I agree that voting +1 is good to get community thoughts, but it's also about action. We can maintain 10 branches in parallel if we don't have enough people to do the actual work. We need to match the people to what we want to do and what we can really do. TomEE 1.7 and TomEE 7 --> EOL, the migration to 8.x is anyway straightforward We can't EOL 9.x if we don't have 10.x production ready and released. This is in my opinion not even a question Back to the first point, I tend to focus myself on the latest version with new development and not really on old versions. I don't think it helps people to migrate if we keep maintaining old versions forever. I like the overall policy: don't release a version if we are aware of affected CVEs. If we can't fix them because it's an unmaintained library, then well we can't do anymore releases on that branch. I also like the idea of giving people a clear view and enough time (7 months) to migrate with the exception of 8.x which obviously requires more work. Jakarta EE 11 is close and it will be the 3rd jakarta based release, so December 31st for TomEE 8.x EOL sounds good to me. We by design depend on many libraries and other open source projects, and it's obvious that there are a lot of chances that at least one of them will be discontinued or not receive any CVE fixes. Hope it helps -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Feb 13, 2023 at 7:57 PM David Blevins <david.blev...@gmail.com> wrote: > 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 > >> > > > >
