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