Hi Michael,
That sounds interesting, I propose to create a Jira of maybe even a wiki page
for that, maybe a new thread to discuss?
Jacques
Le 04/01/2022 à 17:58, Michael Brohl a écrit :
+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
