Thanks all, looks like we have an agreement on 3 points, I have created a PR to add those in Project Guidelines: https://github.com/apache/airflow/pull/15168
For *testing*, I have not received enough feedback yet. Only Tomek and I have said something about it yet. I will wait for a week to hear any other thoughts on it before a create another PR to say "Not all changes need strict testing, "best-effort" and judgement is fine enough for providers because of the low-risk nature of them." Regards, Kaxil On Thu, Mar 11, 2021 at 10:37 AM Ash Berlin-Taylor <a...@apache.org> wrote: > Not releasing doc only changes sounds like a better solution, and fair > point about SemVer, I was just thinking about what is possible with python > versions. > > On Tue, 9 Mar, 2021 at 22:42, Vikram Koka <vik...@astronomer.io.INVALID> > wrote: > > I agree with *Batch vs Ad-hoc *and *Frequency.* > > For doc-only changes, I would prefer NOT to change the version. Primarily > because of the end user perspective, as was articulated earlier in the > thread. > > Best regards, > Vikram > > > On Tue, Mar 9, 2021 at 6:05 PM Jarek Potiuk <ja...@potiuk.com> wrote: > >> Fully agree batch and ad-hoc approach as well as with the frequency. >> >> For docs-only changes I think -post release in PyPI is not a good >> idea. It does not follow semver (https://semver.org/). The only way you >> can extend the number in SEMVER is for pre-releases: >> >> > A pre-release version MAY be denoted by appending a hyphen and a series >> of dot separated identifiers immediately following the patch version. >> Identifiers MUST comprise only ASCII alphanumerics and hyphens >> [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT >> include leading zeroes. Pre-release versions have a lower precedence than >> the associated normal version. A pre-release version indicates that the >> version is unstable and might not satisfy the intended compatibility >> requirements as denoted by its associated normal version. Examples: >> 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–. >> >> Not only violating the semver but this might break a number of tools. >> >> However, I think we can do a different thing in this case. I do not think >> we strictly need to release the packages when we see doc-only change. What >> we can do - we can simply tag it with *-doc1, *-doc2 tags in the repo and >> add some logic to "skip" such doc-only commits next time when we prepare >> packages. >> Then we can simply skip (automatically) building/releasing/voting >> doc-only packages at all, However we will continue with documentation and >> only release the documentation (using the existing version). >> >> Unlike packages, our documentation is mutable and we can override it. >> >> J. >> >> >> >> >> >> >> >> >> On Tue, Mar 9, 2021 at 7:52 PM Tomasz Urbaszek <turbas...@apache.org> >> wrote: >> >>> I'm ok with batch and ad-hoc approach as well as with the frequency. >>> >>> In case of docs-only changes I second what Ash proposed - let's not >>> alter the version. 100% of functionality is the same so users are not >>> affected and there's no need to update. >>> >>> As per testing I agree that E2E testing of all providers should not be >>> necessary to cast +1 vote. The point about ad-hoc releases allows us to >>> release a fix to a provider if users find something that is broken >>> beyond acceptance. >>> >>> Tomek >>> >>> >>> On Tue, 9 Mar 2021 at 11:15, Ash Berlin-Taylor <a...@apache.org> wrote: >>> >>>> For doc-only changes there is one extra thing to decide: >>>> >>>> Should we do it as a patch version (1.0.2 etc) or as a "post" release? >>>> Python packages have this concept: >>>> https://www.python.org/dev/peps/pep-0440/#post-releases >>>> >>>> > Some projects use post-releases to address minor errors in a final >>>> release that do not affect the distributed software (for example, >>>> correcting an error in the release notes). >>>> >>>> So we could update our tooling to support this, or we could just bump >>>> the patch version and release re-release it. >>>> >>>> I have an ever so slight preference for doc only changes to be done >>>> this way, as I think is clearer to users that they don't have to update. >>>> >>>> What does everyone else think? >>>> >>>> -ash >>>> >>>> On Mon, 8 Mar, 2021 at 22:38, Kaxil Naik <kaxiln...@apache.org> wrote: >>>> >>>> Hi all, >>>> >>>> I would like to open the release process of providers up for >>>> discussion. Testing and Voting needs more discussion, the other points are >>>> mostly straight-forward and had an agreement on the last dev call. >>>> >>>> (Backport Providers won't be released after the end of this month - >>>> link >>>> <http://apache-airflow-docs.s3-website.eu-central-1.amazonaws.com/docs/apache-airflow/latest/upgrading-to-2.html#support-for-airflow-1-10-x-releases> >>>> so >>>> let's ignore them in conversation) >>>> >>>> *Batch vs Ad-hoc*: >>>> >>>> - Release Manager would default to releasing Providers in Batch >>>> - ad-hoc releases are OK (i.e. if there is a critical bug that >>>> needs fixing in a single provider) >>>> >>>> *Frequency:* >>>> >>>> - For Batch release, we will release *every month *(starting of the >>>> month - 1 to 7 most likely) >>>> - Just a note that it generally takes around a week for the vote to >>>> pass even though we have 72 hours minimum period >>>> >>>> *Doc-only changes* >>>> >>>> - When we have doc-only changes for Providers (during >>>> batch-release), we should still release a new version. The majority on >>>> the >>>> Dev call had agreed that releasing docs asap is good instead of waiting >>>> for >>>> the next release with a code-change. >>>> >>>> *Testing* >>>> >>>> - License and Signature Checks are mandatory (following the ASF >>>> rules) >>>> - For Providers, not all changes require strict testing -- you make >>>> a judgement based on the changes for a particular provider >>>> - Wherever possible community can help test those but not >>>> strictly necessary. *This is where more discussion is needed. * >>>> >>>> *Voting* >>>> >>>> - Automate and create separate voting threads to avoid confusions >>>> vs a single vote where we exclude the providers if someone finds a bug, >>>> let's keep the discussion for this on >>>> >>>> https://lists.apache.org/thread.html/r9dcc03840f478669e9bd0dc61f4088b725097da2b48ea274b7f0593e%40%3Cdev.airflow.apache.org%3E >>>> >>>> Regards, >>>> Kaxil >>>> >>>> >> >> -- >> +48 660 796 129 >> >
