What is the reasoning behind the trend to lesser maintenance releases for current versions?

[VolkerBarth]

Note: This is a question thast came up in a discussion with Laura Nevin on the documentation of changes in previous versions.

There seems to be a trend towards lesser maintenance releases (MRs) in current SA versions compared to older ones. The following list shows the last MR for the last SA/ASA version (as far as I can recall):

• SA 5.5.5
• ASA 6.0.4
• ASA 7.0.4
• ASA 8.0.3
• SA 9.0.2
• SA 10.0.1
• SA 11.0.1
• SA 12.0.?

And there seems to be a trend that GAs and MRs are nowadays released in chronological order, i.e. 11.0.0 (GA) was released a while after 10.0.1 had been released.

For older versions, it was different: IIRC, the last MR of Vx was often released after the GA of Vx+1, e.g. for V5/V6 or V8/V9. Therefore, the later MRs of older versions might include a few features not available in the GA of the next major version. (This makes it difficult to hold a statement like "Feature XY was introduced in Vx.y".)

---

Out of curiosity, what are the reasons for this trend towards a more-straightlined release cycle? - If there are some publishable reasons except the obvious "This way we expect to serve our customers better", I'd be glad to get to know some of them.

(And no, I'm in no way criticizing this trend...)

[MarkCulp · Accepted solution]

There are likely many reasons for this trend, but here are a few observations:

In earlier days there was a trend to push more changes into already released versions in order to get features out to our customers as quickly as possible and the best way to do this was to do a maintenance release (MR) in order to fully test the software. In recent times (i.e. the last several versions) the development team has strongly held back this urge in order to reduce the possibility that a change of behavior is introduced into the MR.

Looking back at the versions, 7.0.4, 8.0.3 and 9.0.2 were nothing but "bug fix roll-ups" of their respective codelines and the MR was just an opportunity to get through a full cycle of QA tests. Doing these MR cycles took (and still takes) an extreme amount of work (on the order of three to six months). Since those days a greater amount of effort goes into testing an Express Bug Fix (EBF); the amount of testing that goes into an EBF is now closer to that of an MR. As a result there is not as much need to do "bug fix roll-up" MRs (and I hope you agree with me on that?).

We are continuously working toward improving our automated tests in order to improve the quality of all of our releases. For example, Glenn Paulley recently attended the Dagstuhl conference on Robust Query Processing and he blogged about it here.

[VolkerBarth · Accepted solution]

Mark, thanks for the explanation - this seems very reasonable. And no, I don't wait for a current "bug fix roll-up":)

[VolkerBarth · Accepted solution]

BTW: The fact that nowadays EBFs are tested more thoroughly tested than in older versions could be pointed out stronger, methinks, as some folks still seem to consider EBFs as being not that well tested and generally refrain from them...

[reimer_pods · Accepted solution]

I remember having read "Don't install any EBF unless you're sure it solves an issue with your current version" or the like. In my experience I've had only very few cases where an EBF introduced a misbehaviour whe stumbled upon, so I would be more optimistic today.

[MarkCulp · Accepted solution]

@Reimer: The general rule of "don't change anything if it isn't broken" is still a good rule to follow.