Re: Release metadata from `reporter.apache.org`

[Piotr P. Karwasz]

Hi Daniel,

On 30.12.2024 09:31, Daniel Gruno 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

is stored?


https://projects.apache.org/json/foundation/ is probably what you are 
looking for.


No, I am looking for the pairs of "release tag" and "release date" that 
are used by the PMC report generator.


The data in `releases.json` only contains the releases in 
`downloads.apache.org`, but does not contain any data on the 
archived/retired releases.


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.


Looks like an interesting work. I almost regret not being a Python dev 
to apply for the open position.


I will be following the work on Common Lifecycle Enumeration at 
Ecma/OWASP to make sure their lifecycle events are compatible with the 
Apache way.


Piotr



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Release metadata from `reporter.apache.org`

[Daniel Gruno]

On 12/30/24 19:31, Dave Fisher wrote:




On Dec 30, 2024, at 12:31 AM, Daniel Gruno  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 

is stored?


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/ 
 
supported-versions.html
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org 

For additional commands, e-mail: dev-h...@community.apache.org 




-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org 

For additional commands, e-mail: dev-h...@community.apache.org 






-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org