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 >
