Re: Backporting changes between 8.x, 9.x and 10.x

[Richard Zowalla <rz...@apache.org>]

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 <ce...@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 (<rz...@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.gallimore@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.blevins@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
> > > > > > > <rz...@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.
>