Thanks for all the opionions and answers, so far. Here are my thoughts on the branches:
## TomEE 10.x Happy to help - currently, I have a bit of work to do for my $$-job, though, but hope to have some more time to work on it soon :-) ## TomEE 9.x I am fine to help maintaining this one for a short period of time (until we have some a 10.x release) and fixing bugs, etc. (like the *.exe issue yesterday). If we can't upgrade to Tomcat 10.1 without breaking the EE9.1 TCK, we would need to volunteer time in Tomcat to maintain 10.0.x, which they eol'ed a few months ago. I most likely won't have time for that as I would like to focus on EE10. ## TomEE 8.x I am fine with the proposed date / strategy regarding transient dependencies. Regarding CXF 3.5.x - I think, that it should be possible for EE8 to upgrade. I have a related PR, which is sufficient to have a green build, but don't know the TCK status for it [1]. I am also happy to help maintain this branch until we have an EE10 release ready. ## TomEE 1.7.x / 7.0.x / 7.1.x It seems, that we have an agreement on marking 1.7.x and 7.1.x / 7.0.x as discontinued. We currently have a note on the download page for these versions: "Note: TomEE 1.7.5 was released five years ago. New releases from this branch are unlikely, but we are open for contributors to step up and lead the efforts in fixing CVEs and updating dependencies." We might need to make it a bit more clear though. I like the idea by Jon to add a list of CVEs for each of the discontinued release lines. We could even move these artifacts to a separate download page (not archive!) and explicitly mention CVEs + unlikeliness of future releases, so there isn't a false impression on the actual downloadpage, that these artifacts are still maintained, etc. [1] https://github.com/apache/tomee/pull/1010 Am Dienstag, dem 14.02.2023 um 10:58 -0600 schrieb Cesar Hernandez: > +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 > > > > > >
