potiuk commented on issue #480:
URL: 
https://github.com/apache/tooling-trusted-releases/issues/480#issuecomment-3841231699

   Some more details:
   
   1) We already have "apache" organisation in PyPI that all projects should be 
transferred to: https://pypi.org/org/apache/ (this will allow centralized 
Trusted Publishing configuration and possibly in the future implicit namespaces 
for PyPI following https://peps.python.org/pep-0752/ if it gets approved 
eventually
   
   2) The organization in PyPI allows to have Teams defined - so each PMC 
publishing their artifacts will be able to have their own distributions managed 
by them (that however requres likely a PyPI API to mange those - and it is 
currently not available)
   
   3) When you are publishing RC candidates to PyPI - those candidatest are 
`different` than the final releases (rc version needs to be embedded in the 
package - also you might need to refer to other - unreleased yet packages with 
different limits - for example `apache-airflow-providers-google` :19.10.0rc1 
might need to refer to `apache-airflow-providers-common-compat` as `>= 
1.20.0rc1`  - because 1.20.0 is not released yet (when the two packages are 
released together) - and the final package will have `>=1.20.0` - which would 
not allow the RC package to be easily installed. 
   
   Therefore we need a way to have two variants of packages in `dev`:
   
   a) distributions that are released as RCs in PyPI
   b) distributiosn that will be released in final, when the RC is promoted to 
final when voting succeeds. 
   
   If we are going to run SVN trusted publishing  in place, both variants 
should be place in SVN and voting should be done on both of those, and the PMCs 
releaseing PyPI packages should have a convention which will distinguish those 
packages - Trusted publishing should allow to pubklsh the RC packages from dev 
(for the RC variant) and final packages from release (for the "final" variant).


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to