How will it look branch-wise? Currently, if a feature passes a review, it ends up in master, together with bug fixes. If we were to separate bug fixes from features, then we need a different branching structure. For example, we may have another release branch which will get cherry-picked bug fixes, but not the features.
Is this what you had in mind? D. On Fri, May 13, 2016 at 2:21 AM, endianignite <[email protected]> wrote: > 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. >
