+1
with a few additions: I think that the project should have a planned
roadmap with more or less fixed release dates/cycles and a clear
pre-planned EOL plan.
We should also specify what EOL means for us and if there is a step
between. I think of making bugfixes/backports during main support and
only doing security fixes in a phase after that. EOL would then mean
ultimately no fixes at all.
For new release branches, we should als TRY to plan which features, big
changes or deprecations we want to put in and work towards those goals
(thinking about major framework changes etc. as we started to discuss
recently).
We should also think about another release number scheme. The inclusion
of the year/month the branch was created makes the first stable release
look outdated as we normally have a stabilization time of 2-3 years
(which we also could change). Maybe that's a discussion for past-22.x....
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 04.01.22 um 16:04 schrieb Jacques Le Roux:
Hi All,
I'd like to discuss about OFBiz releases EOL (End Of Life) announcement.
For instance R17.12 is EOL with 17.12.08. I suggest to make it clear
on site (if that's not already enough, eg*), to send an email to user
ML and maybe talk about it in social-media and the blog.
Maybe we could also have a special site page for EOL dates and version
of our releases? And some words in
https://ofbiz.apache.org/security.html...
* https://ofbiz.apache.org/release-notes-17.12.08.html (maybe the de
facto standard term EOL (End Of Life) is missing?)
Opinions?
Jacques
Le 04/01/2022 à 11:52, Jacques Le Roux a écrit :
I agree Jacopo,
Will you handle it?
I made those tiny changes after an answer Mark J. Cox made to Mark
Thomas in a discussion I read on security-disc...@community.apache.org :
MT: <<We need to consider whether projects that are not releasing
regularly really are healthy. Could they realistically respond to a
security vulnerability in a reasonable time frame? If not, we need to
move them to the attic.>>
MC: <<And we need a clear way to communicate that, and EOL
releases, to users so
they know the status of what they're using. There are quite a
number of
examples where a project has responded to a vulnerability reporter
that
some version is EOL but it's not been clear enough on their pages,
nor any
real announcement ever having being made. We need a consistent
policy on
what to do about vulnerabilities that come up in EOL versions, and
when to
allocate them CVE names ('there's an unfixed issue in X") in order
to help
users with scanning tools also notice when they're using out of
date and
now insecure projects.>>
There are at least 340+ TLPs*. So I guess it becomes worrying for the
ASF.
I don't think we are concerned by those worries. So was just a small
effort in this direction.
I think though that we should discuss about how to handle EOL
announcements.
*
https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
Jacques
Le 04/01/2022 à 10:45, Jacopo Cappellato a écrit :
Thank you Jacques for adding the statement: however I think it is >
time to remove the entire section of 17.12.08 since we have enough >
releases out of 18.12 already. The release 17.12.08 will always be >
available in the archive. > > Jacopo
