On 12/30/24 19:31, Dave Fisher wrote:
On Dec 30, 2024, at 12:31 AM, Daniel Gruno <humbed...@apache.org> wrote: On 12/30/24 09:09, Piotr P. Karwasz wrote:Hi all, Do you know where the release metadata we supply in: https://reporter.apache.org/addrelease.html <https://reporter.apache.org/addrelease.html> is stored?https://projects.apache.org/json/foundation/ <https://projects.apache.org/json/foundation/> is probably what you are looking for.I am planning to use it to generate some versioning guides for Apache projects, like the "Supported versions" page in Airflow[1]. For simple projects that follow semantic versioning and have a single development line, this should be enough to: * tell users that all updates (including security updates) to a minor version (e.g. 1.10.x) cease once the next minor version is released. * tell users that security updates to a major version (e.g. 1.x) cease after some reasonable time from the release of the next major version. In a second phase I plan to allow PMCs to override the automatically generated data in their DOAP files, by extending the Apache DOAP ontology. The ultimate goal is to generate machine-readable metadata that security scanners could use to tell users that: * commons-ognl is incubating (not ready for production), * Log4j 1.x is EOL and even security reports are no longer accepted. * Log4j 2.23.x is EOL, will never see a new release, but security reports are accepted and will be published. Security updates will of course be published as Log4j 2.24.x. * Aurora effectively reached EOL in February 2020.Projects may or may not have their own EOL policies.While we do not have centralized EOL markers at present, this is part of the overall roadmap for the new release platform, along with other improvements in metadata such as vote/release audit logs and SBOMs. The platform will fall under the new Tooling team, which is expected to start up within a month or two, I believe.Yes. This is definitely part of the roadmap. There are lots of useful pieces of code in ComDev, the Incubator, Whimsy, and Infrastructure. Also, work is likely in STeVe. There will be challenges with EOL metadata. EOL can be imputed from which releases the project has left in the apache list repository, but that doesn’t help consumers know about the planned EOL. To do that accurately will require encouragement for projects to update metadata about each release in a consistent manner. Until that gets planned and reaches a usable point perhaps the best discussion here would be a discussion about what metadata would be useful.
Early stages of a proposed metadata format can be found at https://artifacts.apache.org/docs/adp-yaml.html
There is also a more verbose specification at https://artifacts.apache.org/docs/adp-yaml-spec.html though it lacks one or two items from the other page. TBD!
I would suggest that those interested in metadata standards for our releases look at this and propose their own changes/additions on the artifacts platform mailing list[1] for the time being. When Tooling is properly set up, they can review the ideas.
[1] artifa...@infra.apache.org
https://lists.apache.org/list.html?artifa...@infra.apache.org
For example, a project will have one or more products, one or more repositories. Each repository may or may not be used by one or more of the products. Each product may have one or more versions (whether or not semver is used). Each of those versions may or may not be still supported with an “active” release. As you can see we have a rich object model. It will be important that we model these fully and correctly in the next couple of months. This will help assure that the new tooling team can be effective quickly with fully useful tools. Best, Dave as VP, Tooling.Piotr [1] https://airflow.apache.org/docs/apache-airflow/stable/installation/ <https://airflow.apache.org/docs/apache-airflow/stable/installation/> supported-versions.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org <mailto:dev-unsubscr...@community.apache.org> For additional commands, e-mail: dev-h...@community.apache.org <mailto:dev-h...@community.apache.org>--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org <mailto:dev-unsubscr...@community.apache.org> For additional commands, e-mail: dev-h...@community.apache.org <mailto:dev-h...@community.apache.org>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
