[GitHub] [airflow] potiuk edited a comment on issue #11425: Describe provider versioning changes with semver

[GitBox <gi...@apache.org>]

potiuk edited a comment on issue #11425:
URL: https://github.com/apache/airflow/issues/11425#issuecomment-749647496


   Hello everyone here. I wanted to propose some vision of the 'separate provider' versioning that we should implement as part of cleanup and release Google Provider.
   
   We are already planning to release 2.0.0 provider for Google as it will contain breaking changes due to non-compatible Python API 2.0 libraries. So we will have a chance to test the extreme version,
   
   My proposal:
   
   1) We should add 'current version' of the library to provider.yaml. This might be the top "version" name in the list of versions simply. This way we avoid duplication.
   
   2) For every released version of provider we add a tag in the repo (currently this means 60 tags): Example: 'providers-google-1.0.0'. 
   
   3) We slightly change the way we generate release notes. We will simply get the list of commits from the `providers-google-<PREVIOUS_VERSION>` tag.
   
   4) We remove all the generated CHANGES_* and README_* files completely and instead of keeping them in the repo, we will generate them automatically when the documentation is generated and place it as part of the 'per-provider' documentation.
   
   5) Similarly as we currently do with Airflow's UPDATING.md, we keep the information about breaking changes in the ADDIITONAL_INFO.md (which is already there for some packages). This additional info is automatically part of README.md. We should make sure that any breaking changes or new features added are reflected in the ADDITIONAL_INFO.md during PR Review. This should be author's responsibility to describe it and reviewer's responsibility to point out that it should be updated when we see new feature/backwards incompatible changes. We should add them in "master" version and just before release we decide what is the new version and we update it in a separate commit.  We can even rename ADDITIONAL_INFO to UPDATING to keep consistency or rename it to something different. I am open for proposals. This will also become a better "readable" description of what has changed between different versions. 
   
   6) We will add a tool/view/smth to show each provider together with ADDITIONAL_CHANGES and list of affecting commit in a single summary page, so that we can decide when to release which providers. 
   
   
   I think this is a minimal but pretty comprehensive set of things that we have to implement in order start releasing providers independently and more frequently and if we agree that this looks good, I can split it into issues and start implementing it.
   
   Let me know what you think @kaxil @ashb @mik-laj @turbaszek @XD-DENG others interested :).
   
   
   
   
   
   
   
   
   
   


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

For queries about this service, please contact Infrastructure at:
users@infra.apache.org