Release metadata from `reporter.apache.org`

[Piotr P. Karwasz]

Hi all,

Do you know where the release metadata we supply in:

https://reporter.apache.org/addrelease.html

is stored?

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.

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

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

[Daniel Gruno]

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.


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.




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

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

[Dave Fisher]

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

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 
>