• Motivation
• Description
• Risks and Assumptions
• Discussion Links
• Reference Links
• Tickets

Motivation

It is hard to believe that modern distributed databases can live for years without having releases with breaking backwards compatibility changes as the Apache Ignite does. The lot of @deprecated methods in the API and many obsolete documentation pages leads to a bad user experience. Moreover, the same problem exists for maintaining the obsolete source code for developers and blocks using modern technologies and the latest development language features. 

Here are a few Apache project examples with the same approach:

• Apache Kafka - https://abi-laboratory.pro/index.php?view=timeline&lang=java&l=kafka-clients
• Apache Hadoop - https://abi-laboratory.pro/index.php?view=timeline&lang=java&l=hadoop
• Apache Spark - https://abi-laboratory.pro/index.php?view=timeline&lang=java&l=spark-core

Description

Versioning

Use three digits for the version of Apache Ignite: grand.major.bug-fix[-rc_number]

...

• The persistence data store format without changes (cluster must be able to start from last persistence data store)
• Long-term support with big-fix updates from at least one year the previous 2.xx release
• All the deprecated JMX metrics should remain

Deny features

• turn off atomic operation inside transactions by default

• deny async operation inside transactions

Remove obsolete features

• remove ignite-aop
• remove ignite-schedule
• remove Old Service Grid implementation
• remove MVCC

...

I think the grand release version which contains the new Ignite architecture must be determined when the pre-release source code will be available.

Discussion Links

// Links to discussions on the devlist, if applicable.http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-IEP-69-The-evolutionary-release-process-td51655.html

Reference Links

// Links to various reference documents, if applicable.

...