+1 working on maintaining TomEE 9 branch since currently is the only option users have to migrate to Jakarta namespaces with a TomEE GA version.
+1 on TomEE 8 strategy to check transitive dependencies reaching EOL to analyze its life span. +1 on label TomEE 7.x and 1.7 as discontinued. El mar, 14 feb 2023 a las 5:03, Jonathan Gallimore (< jonathan.gallim...@gmail.com>) escribió: > 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 > > > > > > > > -- Atentamente: César Hernández.
