ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: [DISCUSSION] IEP-69 The evolutionary release process
Date Wed, 17 Mar 2021 02:27:56 GMT
Hi Maxim,

Thanks for summarizing. +1 for the versioning scheme.

-Val

On Tue, Mar 16, 2021 at 11:05 AM Maxim Muzafarov <mmuzaf@apache.org> wrote:

> Folks,
>
>
> Thanks to everyone for participating in the call. Here is the list of
> points we've agreed on and the list of actions which should be
> discussed in more details.
>
>
> = AGREED =
>
> == Versioning ==
>
> grand.major.bugfix[-rc_number]
>
> The 'grand' version is fixed while both Ignite architectures (current
> version 2.x and 3.x) are in a state of active development/maintained
> or until otherwise is discussed further. This means:
> - the master branch of the ignite repository [2] always release under
> the '2.x.x' version
> - the main branch of the ignite-3 repository [1] always release under
> the '3.x.x' version
>
> The 'major' versions for each architecture may contain breaking
> backwards compatibility changes compared to the previous one if the
> following criteria are met:
> - users should be warned about breaking release changes (the ways of
> notification should be additionally discussed and agreed upon)
> - the deprecation rules may be applied for the current 'major' release
> (the ways of deprecation must be additionally discussed and agreed
> upon)
> - current @deprecated already have enough time live and some of them
> can be removed using common sense
>
> The 'bugfix' version is used for emergency releases and can't contain
> any breaking backwards compatibility changes.
>
> == Commitments ==
>
> Any commitment to support previous releases (e.g. 1 year, 1 quarter)
> have no sense to the open-source Ignite community in the case of
> observed backward compatibility violations, however, in any of such
> cases, an emergency release can be performed according to the accepted
> release procedure.
>
>
> = DISCUSSION & SUGGESTIONS =
>
>
> == Deprecation rules ==
>
> The API deprecation rules must be discussed and agreed upon in more
> details. The list of options we have:
> - deprecate and remove API allowed in the next release
> - deprecate and remove API allowed through the one release
> - deprecation may contain comments - the release version then the API
> will be changed
> - deprecation may contain comments - the date from which the API changes
> allowed
>
> I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which
> adds the `forRemoval` and `since` optional elements to the deprecated
> annotation and I think we can use a similar approach here with some
> additions. For instance, if the last released version is 2.10 my
> suggestions would be the following:
> - [case: change API as quickly as possible] mark some API as
> deprecated, set 'since' version 2.12, change it in the 2.12 release
> major version.
> - [case: deprecate API without intention to change] mark API as
> deprecated without 'since' options, change it without notifications
> since 2.13 releases and so on.
>
>
> == User notification rules ==
>
> Uses must be well-notified about the planned backward compatibility
> violations. The options we have:
> - the notification thought the source code with well-described JavaDocs
> - add labels to the JIRA issue if some deprecations occur in the related
> patch
> - add deprecation and backward compatibility paragraph to the RELEASE_NOTES
> - add a page to the Apache Ignite website with a backwards
> compatibility description between the closest versions
>
> All of the above must be done.
>
>
> == Experimental and unstable APIs ==
>
> The options we have:
> - only the new API can be marked as unstable and/or experimental
> - such APIs can be changed without any notifications
>
>
> Please, share your thoughts.
>
>
> [1] https://github.com/apache/ignite-3
> [2] https://github.com/apache/ignite
> [3] https://openjdk.java.net/jeps/277
>
> On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov <dpavlov@apache.org> wrote:
> >
> > Folks,
> >
> > let me add my 50 cents. I don't see major issues with this IEP, for now.
> > And I really looking forward to talking about it. I can't get what causes
> > misunderstanding.
> >
> > The only thing that concerns me here is that IEP requires the community
> to
> > support solutions for 1 year, 1 quarter, etc.
> >
> > Apache community is not a commercial company that provides support of any
> > kind, and I would be reluctant to add these or similar statements to any
> > public documents. At any point in time, the community and PMC can vote
> and
> > introduce any major feature breaking compatibility. We tend to avoid such
> > actions to keep users best interest. But it is not a commitment.
> >
> > Sincerely
> >
> >
> > чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov <mmuzaf@apache.org>:
> >
> > > Val,
> > >
> > >
> > > I'm sorry if anything from what I've said sounded disrespectful. All
> > > of you are examples for me to follow :-)
> > >
> > > Have you checked the `motivation` [1] topic on the IEP-69 page? Should
> > > I add more details to it prior to the call? I want to make Ignite
> > > better and also think that the current 2.x version with all the
> > > advantages and disadvantages is far from exhausted its capabilities.
> > > I'm pretty sure the same motivation page exists for 3.0 version
> > > describing the advantages and disadvantages of developing mentioned
> > > IEPs. It will be good to share it prior to the cal also.
> > >
> > >
> > > [1]
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process#IEP69:Theevolutionaryreleaseprocess-Motivation
> > >
> > > On Thu, 11 Mar 2021 at 01:21, Valentin Kulichenko
> > > <valentin.kulichenko@gmail.com> wrote:
> > > >
> > > > Ksenya, thanks for scheduling this so quickly!
> > > >
> > > > Guys, I hope we can make this discussion constructive. Please keep in
> > > mind
> > > > that Ignite 3 is an ongoing project supported by multiple
> contributors,
> > > > committers, and PMC members. Neglecting 6+ months of effort and
> > > suggesting
> > > > that it's just "prototyping some cool features and nothing more" is
> > > really
> > > > bizarre, and, quite frankly, sounds disrespectful to fellow
> developers
> > > > (although I'm 100% sure it was not intended this way).
> > > >
> > > > Maxim, one of the biggest issues I have with your IEP is that I don't
> > > > understand the motivation behind it. If you don't mind, I would like
> to
> > > > suggest that you kick off the meeting with a detailed explanation
> > > > of exactly that. The first step is to achieve a mutual understanding
> of
> > > > each other's goals. Once we do that, I'm sure we will easily find a
> > > > solution.
> > > >
> > > > -Val
> > > >
> > > > On Wed, Mar 10, 2021 at 8:55 AM Kseniya Romanova <
> > > romanova.ks.spb@gmail.com>
> > > > wrote:
> > > >
> > > > > Let's make a quick call next week and try to find a compromise
> which
> > > can
> > > > > get the process moving:
> > > > >
> https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/276851588/
> > > > >
> > > > > ср, 10 мар. 2021 г. в 16:27, Maxim Muzafarov <mmuzaf@apache.org>:
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > >
> > > > > > Agree, the discussion may be endless without compromises on
all
> > > sides.
> > > > > > I always think that if there is no consensus (and I see from
the
> > > > > > thread [1] that it's was no found) for such important decisions
> like
> > > > > > product future development and releases AFS provides the voting
> > > > > > procedure. Without fixing the results of the discussion [1]
it
> sounds
> > > > > > like prototyping some cool features and nothing more.
> > > > > >
> > > > > > So, back to Denis suggestion can you share - what would be the
> best
> > > > > > time for all of us (considering different time zones) to have
a
> call?
> > > > > >
> > > > > > I also think that we should start a vote about the future
> releases on
> > > > > > our Apache Ignite web-site and user-list, thus all who are using
> the
> > > > > > Apache Ignite may choose the best option they like.
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > > > >
> > > > > > On Wed, 10 Mar 2021 at 03:57, Valentin Kulichenko
> > > > > > <valentin.kulichenko@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Maxim,
> > > > > > >
> > > > > > > I disagree with the suggestions. Several community members
have
> > > already
> > > > > > > pointed out the discussion about Ignite 3.0 [1]. During
that
> > > > > discussion,
> > > > > > we
> > > > > > > did agree on the scope of the changes for 3.0, as well
as the
> > > general
> > > > > > > direction for the product. The new repo was created not
to
> "develop
> > > > > from
> > > > > > > scratch", but to provide an opportunity for the community
> members
> > > to
> > > > > > > actively work on Ignite 3 without killing the Ignite 2.x.
No
> > > > > alternative
> > > > > > > solution for this was presented, so we went ahead with
the
> process
> > > -- I
> > > > > > > consider that to be an example of the silent consensus.
> > > > > > >
> > > > > > > I also want to emphasize that Ignite 3 is active and is
moving
> > > forward.
> > > > > > If
> > > > > > > you look at the ignite-3 repo, commits and PRs are coming
in on
> > > regular
> > > > > > > basis. We also had the first alpha release early in the
year.
> I do
> > > > > agree
> > > > > > > with you, however, that there is not too much activity
on the
> dev
> > > list.
> > > > > > As
> > > > > > > far as I can tell, the main reason for this is that
> communication
> > > moved
> > > > > > to
> > > > > > > IEPs and GitHub PRs, for better or worse. This is something
we
> all
> > > can
> > > > > > talk
> > > > > > > about -- I personally would like to see more discussions
on
> the dev
> > > > > list.
> > > > > > >
> > > > > > > And finally, I agree with Denis. This whole situation is
> > > > > > > counter-productive. I'm happy to jump on a Discord or any
other
> > > voice
> > > > > > chat
> > > > > > > to discuss in more detail.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > >
> > > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-3-0-development-approach-td49922.html
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Fri, Mar 5, 2021 at 11:09 AM Maxim Muzafarov <
> mmuzaf@apache.org
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Ignites,
> > > > > > > >
> > > > > > > >
> > > > > > > > I've created the IEP-69 [1] which describes the evolutionary
> > > release
> > > > > > > > process for the Apache Ignite 2.x version. You can
find all
> the
> > > > > > > > details of my suggestion there, but here you can find
the
> crucial
> > > > > > > > points:
> > > > > > > >
> > > > > > > > 0. Versioning - grand.major.bug-fix[-rc_number]
> > > > > > > >
> > > > > > > > 1. Prepare the next 3.0 release based on 2.x with
some
> breaking
> > > > > > > > compatibility changes. The same things happen from
time to
> time
> > > with
> > > > > > > > other Apache projects like Hadoop, Spark.
> > > > > > > >
> > > > > > > > 2. Discuss with the whole Community and assign the
right
> release
> > > > > > > > version to the activities related to the development
of the
> new
> > > > > Ignite
> > > > > > > > architecture (currently all the changes you can find
in the
> > > ignite-3
> > > > > > > > branch).
> > > > > > > > I see no 3.0 discussions on the dev-list and I see
> no-activity
> > > with
> > > > > > > > the 3.0 version currently. So,  it's better to remove
the
> `lock`
> > > from
> > > > > > > > the 3.0 version and allow the removal of obsolete
features.
> > > > > > > >
> > > > > > > > 3. Guarantee the PDS compatibility between the `grand`
> versions
> > > of
> > > > > the
> > > > > > > > Apache Ignite for the next year.
> > > > > > > >
> > > > > > > > 4. Guarantee the bug-fix release for the last 2.x
Apache
> Ignite
> > > > > > > > version for the next year.
> > > > > > > >
> > > > > > > > 5. Perform some improvements which break the backward
> > > compatibility,
> > > > > > > > for instance: removing @deprecated API (except metrics),
> removing
> > > > > > > > obsolete modules, changing the cluster defaults. You
can find
> > > > > > > > additional details on the IEP-69 page [1].
> > > > > > > >
> > > > > > > >
> > > > > > > > Please, share your thoughts.
> > > > > > > >
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-69%3A+The+evolutionary+release+process
> > > > > > > >
> > > > > >
> > > > >
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message