> On Nov 1, 2026, at 9:42 AM, sebb <[email protected]> wrote:
>
> On Sun, 1 Nov 2026 at 16:39, Dave Fisher <[email protected]> wrote:
>>
>>
>>
>>> On Oct 31, 2026, at 5:27 PM, sebb <[email protected]> wrote:
>>>
>>> On Sat, 31 Oct 2026 at 19:01, Dave Fisher via dev
>>> <[email protected]> wrote:
>>>>
>>>> A couple of notes to add here:
>>>>
>>>> ATR could provide derived DOAP files in the catalog if asked.
>>>
>>> It would be useful to be able to fetch individual entries, rather than
>>> having to download the combined catalog.
>>> Also, the release data section is going to grow and grow, and is not
>>> needed by all consumers, so it would be useful to be able to exclude
>>> that.
>>
>> If the release section only has active releases this will only be bad if the
>> project is not archiving releases. There are a few that don’t.
>
> At present, even releases for Attic projects are included.
> There are nearly 250,000 release entries for 1,500 projects.
>
> In the case of DOAPs, there was no expectation that archived releases
> would be removed.
>
> If the release catalog is intended to replace DOAPs, what happens to
> the archived releases?
The catalog contains archived releases. Perhaps you should explore the static
website.
1. Home - https://release-catalog.apache.org/index.html
2. Example project - https://release-catalog.apache.org/airflow/index.html
3. Attic (may need additional seeding) -
https://release-catalog.apache.org/attic/index.html
4. Incubator - https://release-catalog.apache.org/incubator/index.html
Please feel free to provide feedback to the tooling team via GH issues or
[email protected]
Best,
Dave
>
>>> It might be better to provide the release data as a separate download.
>>> i.e. one or more downloads for the largely static data, and a separate
>>> set for the ongoing release data.
>>
>> We are publishing CLE documents in the catalog about a project’s release
>> lifecycle:
>> https://ecma-international.org/publications-and-standards/standards/ecma-428/
>>
>>>
>>>> We should probably make sure that we have an agreed mechanism for
>>>> maintaining both Categories and Languages lists.
>>>
>>> Also it might be useful to include a notice/comment in the file with
>>> details on where to maintain the source data.
>>
>> We may have a feature gap which the tooling team will discuss next week.
>
> There are several errors I noticed in the data - where is this held?
> And where are changes recorded?
>
>> Best,
>> Dave
>>
>>>
>>>> Best,
>>>> Dave
>>>>
>>>>> On Oct 31, 2026, at 9:47 AM, Andrew Wetmore <[email protected]> wrote:
>>>>>
>>>>> Hi, Rich:
>>>>>
>>>>> Can you add ActionScript to the code categories, and UI to the 'what kind
>>>>> of problems do you enjoy working on'? I am unable to make either Flex or
>>>>> Royale appear in the search process.
>>>>>
>>>>> a
>>>>>
>>>>>
>>>>> Andrew Wetmore
>>>>> Assistant VP, Marketing and Publicity, The ASF <https://apache.org>
>>>>> Editor-Writer, Infra team, The ASF
>>>>>
>>>>> Editor, moosehousepress.com
>>>>>
>>>>>
>>>>> On Sat, Oct 31, 2026 at 8:27 AM Rich Bowen <[email protected]> wrote:
>>>>>
>>>>>> On Fri, Oct 30, 2026, 19:56 sebb <[email protected]> wrote:
>>>>>>
>>>>>>> On Fri, 30 Oct 2026 at 22:09, Rich Bowen <[email protected]> wrote:
>>>>>>>>
>>>>>>>> On Fri, Oct 30, 2026, 17:44 sebb <[email protected]> wrote:
>>>>>>>>
>>>>>>>
>>>>>>> I had not realized that ATR metadata included categories and
>>>>>>> programming languages etc as per the DOAPs.
>>>>>>> In which case I agree, the DOAPs could be dropped if not otherwise
>>>>>> needed.
>>>>>>>
>>>>>>
>>>>>> Yes, ATR initially loaded their data from those DOAP files, but do not
>>>>>> continue to reference them unless you explicitly make a reference to them
>>>>>> in your asf.yaml file.
>>>>>>
>>>>>>
>>>>>>> However, it requires a login to even view the data.
>>>>>>> Also the DOAPs include the data in a single file, whereas it looks
>>>>>>> like ATR only exposes the data via the HTML page.
>>>>>>>
>>>>>>
>>>>>> I'm pulling it from the projects.json file that they publish.
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
