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
