I am all for lazy consensus :)
On Sun, Dec 4, 2022 at 9:16 PM Pierre Jeambrun <[email protected]> wrote: > > 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.
