Thanks for starting this discussion Kaxil, I have been wanting to find
time to finish drafting that release doc and then bring this to the
list.
So yeah, both a and b are compatible with SemVer, which is only
concerned with breaking changes - if you make breaking changes you MUST
increment the major version. You can also add other changes in that
release (and this is what most projects too, and what we did with 2.0)
or you can just make breaking changes/remove things but include no
other changes.
I think from a user wanting to upgrade perspective a) is easier because
you can go to (for example) 2.8, the last in the 2.8 series, ensure you
have no warnings/run upgrade check and then know that you can upgrade
to 3.0 without anything else changing on you.
If we wanted to go with approach a the way it would have to work (to
avoid adding more new features) is that we'd have to release 2.8 (in
this example) then almost immediately remove the features we have
deprecated and then release 3.0. If there is any kind of meaningful gap
between these releases (say more than a few days) then there is a high
likelyhood that new features would be added.
I proposed this idea, but I don't have strong feelings which way we go
- both have pros and cons.
-ash
On Tue, 9 Mar, 2021 at 22:29, Vikram Koka
<[email protected]> wrote:
I love the thoughtful discussion.
I am in favour of (b), because that is the "general understanding" of
Semantic Versioning.
On Tue, Mar 9, 2021 at 6:14 PM Kaxil Naik <[email protected]
<mailto:[email protected]>> wrote:
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
