ID | IEP-69 |
Author | |
Sponsor | |
Created |
|
Status | DRAFT |
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:
Use three digits for the version of Apache Ignite: grand.major.bug-fix[-rc_number]
All planning releases will be major release by default. However, after a reasonable period of time but not earlier than a year from the last grand release some of the changes may break the compatibility. In this case, the grand version will be bumped up. The following changes may break the compatibility:
For each breaking change the following guarantees need to be provided:
The previous grand version of the Apache Ignite guaranteed to be supported with bug-fix releases no more than once a quarter.
The total amount of changes for this release must be not so big. Thus, two or three community members may complete them within a few months.
turn off atomic operation inside transactions by default
deny async operation inside transactions
remove DiscoverySpi#failNode()
Risks and Assumptions
There are some public activities with the 3.0 Ignite version that already happened e.g. the 3.0-alpha version creation, some public online meetups. Thus, the main risk associated with the release of the new 3.0 version is mainly related to marketing activities. However, the amount of changes for the new Ignite architecture is too big to be completed within the next few years. The stabilization period of such a version may take even more time.
I think the grand release version which contains the new Ignite architecture must be determined when the pre-release source code will be available.
// Links to various reference documents, if applicable.
// Links or report with relevant JIRA tickets.