Dear Igniters, First of all, congratulations on heading towards the 1.6 release. Each Ignite release is a huge amount of work, done to a very high standard by a great group of people. I raise my hat to each and every one of you!
I would like to open a discussion regarding release schedules, and how we currently perform releases. Right now, we have very large waterfall releases, that are a combination of substantial numbers of bug fixes, along with significant new features - binary marshaling from 1.5 is one that I witnessed first hand. The integration of all of these changes can be challenging, and from my observation tends to extend the time taken to go from the final code freeze to the point of release. Some data from the release dates: Release,Date,DaysSinceLastRelease 1.0,02-Apr-15, 1.1,28-May-15,56 1.2,29-Jun-15,32 1.3,21-Jul-15,22 1.4,28-Sep-15,69 1.5,04-Jan-16,98 1.6*,31-May-16,148 1.7+,03-Dec-16,186 1.8+,17-Jul-17,226.7 1.9+,11-Apr-18,267.4 2.0+,13-Feb-19,308.1 *estimated date +extrapolated date. Equation: date=407*releaseVersion-505.9 taken from Excel best-fit line, R^2=0.9906. As you can see, the time between releases is trending upwards since 1.3, and on a very steep gradient. Doing some (admittedly silly) extrapolation, at the current it could take 308 days to go from a future version 1.9 to a 2.0 release, just assuming the current growth rate. This could mean that a bug found in April 2018 would not be released until February 2019! Currently I'm facing a bug (https://issues.apache.org/jira/browse/IGNITE-2080) that was found in Dec-15, fixed in Feb-16, but will not be released until May/June 2015. In my opinion this is not sustainable if we want Ignite to grow in userbase and functionality, whilst retaining a reputation for stability and being bug-free, as I'm sure we all do. Therefore, as a sign of Ignite's growing maturity, I would like to suggest that we adopt a release schedule where bug fixes are released on a timed-release basis, and new features are included in less frequent major releases. There are many examples of this kind of release schedule: Intel's tick-tock cycle, Ubuntu's timed-release cycle, Redhat's major/minor/asynch cycle. I propose that the release schedule for Ignite would be separated in to two streams: bug fixes and major features. The first stream, bug fixes, would close for code freeze every month, undergo testing and QA and then be released, hopefully within two weeks of the code freeze. Bugs not fixed in time for the code freeze would be pushed to the next monthly cycle. The Major Features stream would be over a significantly longer period, although I would still suggest that it be less than the current 3-5 month interval. Finally, if you got this far then well done, you have got staying power. I hope that you will take the above thoughts and analysis in the way that they are offered, as a positive, and not as criticism (which they are not). I'm really interested to hear your thoughts on this subject. I'm happy to try and lead a release cycle change if the community would like me to, or to assist someone within GridGain if that makes more sense. Kind regards Mike -- View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Release-Schedules-a-suggestion-tp8867.html Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
