Hi David, Thank you for the follow-up, I created https://issues.apache.org/jira/browse/TOMEE-4193 and https://github.com/apache/tomee-site-generator/pull/61 for the eol pages.
El jue, 16 mar 2023 a las 13:22, David Blevins (<david.blev...@gmail.com>) escribió: > 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. > > -- Atentamente: César Hernández.
