> You can prove just about anything with statistics. ;)
Very much true :) Two options spring to mind: > > 1. Google donates some time to write system tests for the rest of the > operators. > 2. We release them all with just unit tests After all option 2 is _exactly what we do now for releases_. I am inclined to follow the 2nd one. I fully agree that we aren't doing more for the current releases and that there likely will be some issues. And we can still keep the https://cwiki.apache.org/confluence/display/AIRFLOW/Backported+providers+packages+for+Airflow+1.10.*+series as a "verified working" status for the packages. And we can keep it updated. I can take care of that. But we do not have to make it a condition for release. Either > we're happy the unit tests cover things already, or we shouldn't be > making any releases. (Of anything, including the main airflow package) > Agree. > On a slightly different subject: have we though how/what we are going to > version these packages? > Yes. The proposal was to make the CALVER approach for the packages. 2020.4.20 if we would release it today. I think it makes a lot of sense for the "backport" releases - I assume we might want to release some packages individually with different dates, and having the CALVER approach makes it super easy. You do not have to think about it. Just release it with the current date. We can (and will) still keep release notes for the packages separately. I built in the per-package release notes that we can add separately for each package with the CALVER versioning info. And it should also be rather easy now when they are nicely separated in directories - we can very easily automate preparing release notes using Git log. I plan to do it right after we make the first release. > Are we going for (say) apache-airflow-provider-google==2.0.0, or perhaps > apache-airflow-provider-google==1.99 to mirror what grub2 did for a while. For example 'apache-airflow-providers-celery==2020.4.20' is the proposed name if we release today. And an important question I think we need to answer before we publish > these: What happens to these packages once Airflow 2.0 is out? (Mostly > just how to we avoid any installation problems for our users in the > future. Whether these packages live on or not can be addressed in AIP-8?) > I think we should decide when we release airflow.2.0 and when we agree on the versioning/release schedule. I think both options are on the table. I am inclined to keep the separate packages also for 2.0 and make an AIP-8 a reality - if within the next month or two we find no big issues (and we will have confirmation from the users (and we will see that they actually use the provider packages), we could make it a default approach for Airflow 2.0 as well. I would like to make a more informed decision on that. For now, all those packages have a hard dependency on 'apache-airflow~=1.10', so it will not be possible to install 2.0 without uninstalling the provider packages. However, when we release Airflow 2.0 we can release new versions of packages that will also work with 2.0. >
