Damn,

It seems that no matter what we do - "source" links will always appear
there (after some time :X). But then, we do not have to upload "our"
packages there.

This is what I proposed to the Airflow PMC. Perhaps we can take it as an
example of how it can be "clearly" marked? (you can see it in my Airflow
fork) [1]:

The only authoritative source for Apache Airflow 3.2.1 release
artifacts is the official downloads page at:

https://airflow.apache.org/docs/apache-airflow/3.2.1/installation/installing-from-sources.html
That page lists the source tarballs, wheels, detached .asc signatures,
and .sha512 checksums published by the ASF, with instructions for
verifying each — including the project's signing keys at
https://downloads.apache.org/airflow/KEYS.

Note: the "Source code (zip)" and "Source code (tar.gz)" attachments
on this page are GitHub-generated snapshots of the git tag. They are
not official ASF releases, are not signed, and may differ
from the canonical artifacts on the downloads page above.

[1]
https://github.com/potiuk/airflow/releases/tag/release-rendering-test-3.2.1
-


On Sun, May 3, 2026 at 10:37 PM Jarek Potiuk <[email protected]> wrote:

> > And sorry for getting your name wrong - autocorrect can be the worse
> sometimes
> No problem, it happens to me all the time, Josef ;)
>
> Regarding GitHub releases, I’ve confirmed it is possible to maintain
> release pages containing only release notes without attached binaries.
> Airflow is currently running a lazy consensus [1] to remove binaries from
> GitHub and instead provide links to our official download page [2] and
> PyPI. We will include a note that our PyPI packages are bit-to-bit
> identical to the SVN artifacts and have passed all required checks and
> votes.
>
> I believe this is the best approach because it maintains the familiarity
> of GitHub release notes for users while eliminating concerns regarding
> artifact immutability or multiple "sources of truth." You can see a preview
> of the throwaway script to do in this PR [3] and a live example on my
> private fork [4].
>
> [1] https://lists.apache.org/thread/5x55mvorsrkc4ny16v55d71bbs9djm6y
> [2] https://infra.apache.org/release-download-pages.html
> [3] https://github.com/apache/airflow/pull/66314
> [4]
> https://github.com/potiuk/airflow/releases/tag/release-rendering-test-3.2.1
>
> Thanks,
> Jarek
>
> On Sun, May 3, 2026 at 6:59 PM Jean-Baptiste Onofré <[email protected]>
> wrote:
>
>> Hi Justin,
>>
>> I will check but I guess it's the "default" GH Release. Let me check on
>> the
>> podliings I mentor.
>>
>> Regards
>> JB
>>
>> On Sat, May 2, 2026 at 12:10 PM Justin Mclean <[email protected]>
>> wrote:
>>
>> > Hi,
>> >
>> > I also checked current podlings against the Incubator GitHub
>> distribution
>> > guidance:
>> > https://incubator.apache.org/guides/distribution.html#github
>> >
>> > The following podlings appear to have GitHub Releases that may need
>> > cleanup/extra info added:
>> >  - Burr
>> >  - Casbin
>> >  - Fluss
>> >  - GraphAr
>> >  - Hamilton
>> >  - Iggy
>> >  - OzHera
>> >  - ResilientDB
>> >
>> > Again, this was done with a script and could be incomplete or incorrect.
>> >
>> > Could mentors and PPMCs please check that GitHub Releases include the
>> > incubating disclaimer where needed, and that RCs, nightlies, and
>> snapshots
>> > etc are marked as GitHub pre-releases?
>> >
>> > Thanks,
>> > Justin
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [email protected]
>> > For additional commands, e-mail: [email protected]
>> >
>> >
>>
>

Reply via email to