Hello guys, Just a heads up on this one.
To summarize what we seem to agree on: - for each minor/major release of airflow, we should systematically release new versions of api clients accordingly (python/go clients). - we can patch clients independently to fix specific issues (documentation, generation issues etc.). - when releasing a patch for airflow, *only *if this is relevant for the clients, then we also release clients. (patch version) As Jarek mentioned we could have different patch versions between airflow and clients. *Notes: *We should also update the API version in the OpenAPI spec when releasing airflow. It is sometimes not in sync, at the moment it is pointing to 2.4.0 -> https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html Do you guys think we need more time to discuss this or should I follow up with a vote ? I think this one qualifies for a lazy consensus but I would be glad to call for a 'normal' vote, just let me know :) Best regards, Pierre Le mer. 16 nov. 2022 à 06:17, Sumit Maheshwari <[email protected]> a écrit : > Not with every release. I am talking about releasing it with every release >> "if it is needed". >> > > That clarifies, plz go ahead. > > On Tue, Nov 15, 2022 at 5:15 PM Jarek Potiuk <[email protected]> wrote: > >> And just to add one "clarifying" condition here: >> >> If we release Airflow 2.X.0 (the first release in the MINOR version, >> the answer to "Do we need to release .... API Client ?" is always >> "YES". >> >> J. >> >> On Tue, Nov 15, 2022 at 12:41 PM Jarek Potiuk <[email protected]> wrote: >> > >> > > we are talking about the same thing & on the same page with >> versioning, though releasing clients with each Airflow release confuses me. >> > >> > Not with every release. I am talking about releasing it with every >> > release "if it is needed". I do not see anything confusing here. The >> > logic is simple: >> > >> > * release Airflow >> > * do we need to release Python API Client -> if yes, release >> > * do we need to release Go API Client -> if yes, release >> > * release Docker Image >> > >> > I hope this "algorithm" is pretty straightforward. >> > >> > J. >> > >> > >> > On Tue, Nov 15, 2022 at 12:21 PM Sumit Maheshwari >> > <[email protected]> wrote: >> > > >> > > @Jarek Potiuk we are talking about the same thing & on the same page >> with versioning, though releasing clients with each Airflow release >> confuses me. >> > > >> > > On Tue, Nov 15, 2022 at 4:04 PM Jarek Potiuk <[email protected]> >> wrote: >> > >> >> > >> > >> > >> > There had been a discussion around this earlier, though I couldn't >> find the thread. So if we want to release clients with each Airflow >> release, then we've to move away from current semantic versioning, >> something which we had decided in that thread. >> > >> >> > >> Why ? I think we do not have to do that - the point I made is that >> we >> > >> do not "have" to release the client - but we SHOULD do it if there is >> > >> an outstanding change. >> > >> >> > >> As I mentioned above: >> > >> >> > >> 1) when we release 2.5.0 Airflow -> we always make 2.5.0 API - no >> > >> exceptions here. >> > >> 2) when we release 2.5.n (n != 0) - we MIGHT release API if there are >> > >> some bug-fixes that are relevant (for example we found out that there >> > >> is a documentation fix needed or Python generator fixed some mistake >> > >> in generated code (happened in the past). But this could easily be >> the >> > >> case that when we release Airflow 2.5.3 we also release Python API >> > >> client 2.5.1 and Python Go client 2.5.4 (for example, because in the >> > >> meantime we independently released fixed to Python Go Client 3 times. >> > >> >> > >> Generally our users should install the latest released Python/ Go >> > >> clients for the 2.5 line - no matter which patchlevel they have. >> > >> >> > >> I do not think it requires any changes to our agreed SemVer approach. >> > >> >> > >> But maybe I have not thought about something? >> > >> >> > >> J. >> >
