Interesting points, reminds me of this thread: https://github.com/semver/semver/issues/411#issuecomment-347050750 😄
Some comments / suggestions from the commenters on that post which I find interesting (both of which support one or the other option we are discussing). 1) Use BREAKING.FEATURE.PATCH instead of MAJOR.MINOR.PATCH. 2) To me, a MAJOR version bump means "either I broke something or I really want you to pay attention." Regards, Kaxil On Wed, Mar 10, 2021, 01:51 Jarek Potiuk <ja...@potiuk.com> wrote: > Very slight preference for b) for the marketing value but a) has some nice > properties too and if we have enough support for a) I would also follow > "remove deprecated features only". > > I do not think we break semver with a) : https://semver.org/. Major > version MAY (but not MUST) include minor and patch level changes. So it is > up to us what we decide. > > Major version X (X.y.z | X > 0) MUST be incremented if any backwards > incompatible changes are introduced to the public API. It *MAY* also > include minor and patch level changes. Patch and minor version MUST be > reset to 0 when major version is incremented. > > J. > > > On Tue, Mar 9, 2021 at 7:41 PM Tomasz Urbaszek <turbas...@apache.org> > wrote: > >> I'm also in favor of *b)*. >> >> If we expect that new features may confuse users then maybe we should >> adopt a rule that when a feature is introduced it is protected by the >> feature flag and is not enabled by default. Of course this may not always >> be possible or may create even more confusion. >> >> Cheers, >> Tomek >> >> >> On Tue, 9 Mar 2021 at 09:22, Deng Xiaodong <xd.den...@gmail.com> wrote: >> >>> To me it should be *(b)*, especially given we intend to follow SemVar. >>> >>> People would have specific expectations on MAJOR/MINOR/PATCH >>> <https://semver.org/#summary> if we claim SemVar is followed. *(a)* >>> would cause confusion in such context. >>> >>> >>> XD >>> >>> On Tue, Mar 9, 2021 at 12:43 AM Kaxil Naik <kaxiln...@apache.org> wrote: >>> >>>> I personally would vote for *(b) Contain new features as well as the >>>> removal of deprecated features *as otherwise, it does not feel like it >>>> is a major release to me. >>>> >>>> A major release to me is where we add new features of significant >>>> values as we did with Airflow 2.0.0. >>>> This is also good in terms of marketing where blog posts and video >>>> posts (talks in conferences) can talk about *what's new in 3.0.0? *instead >>>> of 3.1 or 3.2 >>>> >>>> Regards, >>>> Kaxil >>>> >>>> On Mon, Mar 8, 2021 at 11:41 PM Kaxil Naik <kaxiln...@apache.org> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> As part of documenting all the guidelines including (PR here >>>>> <https://github.com/apache/airflow/pull/14674>) but not limited to >>>>> Release, I would like to start the discussion on one of the things that >>>>> was >>>>> recently discussed: >>>>> >>>>> *What should the major version like 3.0.0 / 4.0.0 contain?* >>>>> a) Only removal of deprecated features to ease the migration for users >>>>> b) Contain new features as well as removal of deprecated features >>>>> >>>>> Also Note: from Airflow 2.0.0, we intend to follow SemVer ( >>>>> https://semver.org/) >>>>> >>>>> Looking forward to hearing everyone's thoughts. >>>>> >>>>> Regards, >>>>> Kaxil >>>>> >>>>> >>>>> > > -- > +48 660 796 129 >
