Hi Maxim, Thanks for summarizing. +1 for the versioning scheme.
-Val On Tue, Mar 16, 2021 at 11:05 AM Maxim Muzafarov <[email protected]> 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 <[email protected]> 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 <[email protected]>: > > > > > 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 > > > <[email protected]> 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 < > > > [email protected]> > > > > 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 <[email protected]>: > > > > > > > > > > > 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 > > > > > > <[email protected]> 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 < > [email protected] > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > >
