Maxim, Folks, hi.
The approach looks reasonable to me, +1
As an additional user notification, we might use even/odd number
strategy. User could be sure that even (as an example) major release
doesn’t break backward compatibility. Crucial API changes might be
collected only in odd releases. Moreover, odd majors might be omitted at
all in case of absence of compatibility breach.
16.03.2021 21:05, Maxim Muzafarov пишет:
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 <dpav...@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 <mmu...@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.kuliche...@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....@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 <mmu...@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.kuliche...@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 <mmu...@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
