potiuk commented on PR #47999:
URL: https://github.com/apache/airflow/pull/47999#issuecomment-2745155077

   Nice. But I think we should make an explicit bump as a separate PR in 
`common.compat`. This is something that we should start doing to keep the 
common.compat more of a managed "what's in which version". 
   
   I think #47909 was a bit wrong in the sense that it did not bump 
common.compat version to 1.6.0 - such bump should happen there, because that's 
where the functionality was added, not here where the functionality is "used". 
   
   We can rectify by extracting `common.compat` version bump to a separate PR 
from this one.
   
   We have no good mechanisms for full automation here (yet - maybe we should 
introduce it at some point of time), but for now I think it could be relatively 
easy thing to follow a process similar to this:
   
   1) Make a PR that changes both common.compat - including major version bump 
- and the provider to use the new feature and make it green (do not merge - it 
should be draft).
   
   2) Split out the PR part for `common.compat` - where both "common.compat" 
change and "minor version bump" are done.
   We should also handle the case where we already have an unreleased 
`common.compat" minor version bumped and we want to add "another" functionality 
to it - then we do not need to bump the minor version. That part is a bit 
tricky, because we need to somewhere have the information "common.compat 
already had minor version bumped but it is not yet relased". I have no good 
idea yet how to store that information in an easy way to know it without going 
to PyPI and checking (also being aware that we are just voting new providers 
including commopn.compate which is a bit of an edge case).  Merge it first.
   
   3) Rebase the original PR (effectively removing the common.compat change 
from it) and merging only changes related to the provider that needs new 
"common.compat") - `dbt` in this case.
   
   
   WDYT. @kacpermuda @mobuchowski @eladkal ? Maybe you have some other ideas 
here and maybe we should write-down a small description on how we approach 
common.compat changes? 
   
   


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

Reply via email to