I very much agree with specifying where you're willing to spend your time, as opposed to just what you'd like to see.
- TomEE 10: I'm happy to contribute to the development of that as I can. I'm currently working on the concurrency changes needed for EE10. - TomEE 9: I'm happy to contribute towards maintaining this until a little after TomEE 10 is released. If we discontinued this now, I think users would potentially avoid actually doing their migration from javax to jakarta. I don't see any way we can discontinue this until there is a GA TomEE 10 release. - TomEE 8: I agree we need to determine what its lifespan is, and this is to a certain extent determined by all of the components we use. I suspect CXF may be tricky in this area - as 3.4.10 is the last 3.4 release, and I'm not sure what is involved in 3.5.x or it is suitable for EE8 etc. If we don't determine a lifespan for TomEE 8, there's a real danger that people will try and stick with it forever rather than migrate to newer versions. I'd be happy to help maintain this branch for a short time - Older branches: I wouldn't want to contribute to these any more, and would be in favor of marking them as discontinued. The EOL policy you've suggested is really clear, and I think it strikes a reasonable balance with what's achievable from a maintenance perspective, while giving time for users to upgrade. While I don't necessarily object to releases from older branches, if there was a strong desire to do so, I do think the responsible thing to do is clearly list every single CVE in each library that hasn't been patched on the download page. I personally strongly prefer the policy of not releasing software where there are CVEs in any of the components, however. Jon On Wed, Feb 8, 2023 at 8: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 > > > >
