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

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

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

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

[Thomas Andraschko <an...@gmail.com>]

+1 to NOT maintain 9.x, most people will not use it anyway

Richard Zowalla <rz...@apache.org> schrieb am Di., 7. Feb. 2023, 19:59:

> 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
>
>

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

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Hey David,

Wanted to reply over the weekend but I think I forgot.

First I agree that voting +1 is good to get community thoughts, but it's
also about action. We can maintain 10 branches in parallel if we don't have
enough people to do the actual work. We need to match the people to what we
want to do and what we can really do.

TomEE 1.7 and TomEE 7 --> EOL, the migration to 8.x is anyway
straightforward
We can't EOL 9.x if we don't have 10.x production ready and released. This
is in my opinion not even a question

Back to the first point, I tend to focus myself on the latest version with
new development and not really on old versions. I don't think it helps
people to migrate if we keep maintaining old versions forever.

I like the overall policy: don't release a version if we are aware of
affected CVEs. If we can't fix them because it's an unmaintained library,
then well we can't do anymore releases on that branch.

I also like the idea of giving people a clear view and enough time  (7
months) to migrate with the exception of 8.x which obviously requires more
work.
Jakarta EE 11 is close and it will be the 3rd jakarta based release, so
December 31st for TomEE 8.x EOL sounds good to me. We by design depend on
many libraries and other open source projects, and it's obvious that there
are a lot of chances that at least one of them will be discontinued or not
receive any CVE fixes.

Hope it helps
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Mon, Feb 13, 2023 at 7:57 PM David Blevins <da...@gmail.com>
wrote:

> Any other thoughts?
>
>
> -David
>
>
> > On Feb 8, 2023, at 12:07 PM, David Blevins <da...@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
> >>
> >
>
>

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

[David Blevins <da...@gmail.com>]

Any other thoughts?


-David


> On Feb 8, 2023, at 12:07 PM, David Blevins <da...@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
>> 
> 

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

[somasani nikhil <so...@gmail.com>]

Yes, This will greatly help people with decision to move forward with
upgrade to a specific version.

I would be happy to collaborate with team but I’m very much new to this
process / doesn’t have clear steps on supporting such projects.

Thank you!
Nikhil Somasani

On Fri, 17 Mar 2023 at 12:52 AM, David Blevins <da...@gmail.com>
wrote:

> 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.
>
> --
Thanks and Regards,
Nikhil Somasani

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.
> 

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

[Cesar Hernandez <ce...@gmail.com>]

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 (<da...@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 <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.
>
>

-- 
Atentamente:
César Hernández.

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

[David Blevins <da...@gmail.com>]

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.

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

[Cesar Hernandez <ce...@gmail.com>]

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.

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

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

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
> > > > 
> 
> 

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

[Cesar Hernandez <ce...@gmail.com>]

+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 <da...@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.

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

[Jonathan Gallimore <jo...@gmail.com>]

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 <da...@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
> >
>
>

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

[David Blevins <da...@gmail.com>]

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
>