Hi David, sounds good to me. I think, that Cesar already created that pages on the download page.
Question would be, if we need to do a formal vote? I think, that Tomcat is doing so? wdyt? Gruß Richard Am Donnerstag, dem 16.03.2023 um 12:22 -0700 schrieb David Blevins: > 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. >
