We should maybe also create pages like this as they seem to come up in search engines nicely:
- https://tomcat.apache.org/tomcat-10.0-eol.html <https://tomcat.apache.org/tomcat-10.0-eol.html> - https://tomcat.apache.org/tomcat-70-eol.html <https://tomcat.apache.org/tomcat-70-eol.html> Some kind of URL like this would be great: - https://tomee.apache.org/tomee-8.0-eol.html <https://tomee.apache.org/tomee-8.0-eol.html> We probably also want to add a bullet to the TomEE 8 download section that then links to this page. -David > On Feb 16, 2023, at 8:23 AM, Cesar Hernandez <cesargu...@gmail.com> wrote: > > About the website message for discontinued branches, I created TOMEE-4186 > for a proposal for the Download page that won't move (yet) the discontinued > versions to the archive but instead marked them as discontinued branches. > > As Richard mentioned, having the discontinued version on the actual > download page may create a false impression, so we can have two steps, > first make clear on the download page the branches that are discontinued, > and then after 3 or 6 months, we can move then to the archive section but > keeping the discontinued text in the same way many milestones releases has > the information on the archive page. > > El mié, 15 feb 2023 a las 2:54, Richard Zowalla (<r...@apache.org>) > escribió: > >> 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 >>>>>> >>> >>> >> >> > > -- > Atentamente: > César Hernández.
