Lazy consensus seems fine to me. On Mon, Dec 5, 2022 at 2:11 AM Jarek Potiuk <ja...@potiuk.com> wrote:
> I am all for lazy consensus :) > > On Sun, Dec 4, 2022 at 9:16 PM Pierre Jeambrun <pierrejb...@gmail.com> > 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 <sumeet.ma...@gmail.com> > 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 <ja...@potiuk.com> 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 <ja...@potiuk.com> > 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 > >>> > <sumeet.ma...@gmail.com> 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 <ja...@potiuk.com> > 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. >
