During this coming April, you may notice something peculiar on the
civicrm.org download page -- instead of
4.7.32, you'll see a jump up to
5.0.0. Does this mean that CiviCRM is finally implementing a personal voice-assistant to take-down Amazon Echo? Nope. Maybe it means open-season on changes, granting a general license to break backward-compatibility? Nope. 5.0 is boring. It's basically the same thing as 4.7. It's just a big number with a little change.
OK... what is the little change? In short: a realignment, such that a typical increment looks like
5.x instead of
4.7.x. It doesn't change the substance. It shifts the relation between version-numbers (the superficial numbers you see in
4.5.6) and work (the labor you don't see, from people who triage and code and review and test). Compare:
4.x.0corresponded to roughly 6-10 months of work.
4.7.xcorresponded to roughly one month of work. (Notice a shift toward smaller units-of-work.)
5.x.0corresponds to roughly one month of work. (Notice a change in digits.)
This realigns the digits -- and opens the third digit for smaller revisions, which means:
5.x.0, then we can more easily issue a patch-release
5.xmerits longer security support, then we can issue a longer series of patch-releases.
Of course, in a perfect world, none of that would be necessary -- but in the real world, shipping a quality product requires multiple layers of defense. Diligent developers, conscientious reviewers, extensive automation, timely testing on staging systems, clear design -- all of these help to improve the quality of a complex product, and all of them will miss something sometimes. A good plan includes a contingency. What do we do about the problems that get through despite everything else? That's what the third digit is for.
Q: You suggested that
5.x.x could allow longer security support for particular branches. What's the policy on that?
We're still working through that. We can only handle one big change at time, so please stay tuned to the blog and mailing-lists for future discussion. Thanks for the interest.
Q: Would it be better to say
Maybe. Probably not. They all address the main requirement -- regaining utility of the third digit. They all make a visible change, which requires some kind of explanation/communication. I'd rather focus on the bigger gain than haggle over the small trade-offs.
Q: Would it be better to say
Maybe. Probably not. Our distribution channel has some bits which have been coded/tested for three numerical segments, and changing the number of segments would pose some technical risk.
Q: Does this mean you're going to start making more, bigger, scarier changes more often?
No. This is strictly a superficial realignment of the numbers. In fact, the general trend of editorial policy has been toward tightening rather than loosening standards.
Q: Does this mean you're going to start pushing tiny changes every day?
No. The third digit is a last resort, intended only for clear, recent, critical regressions.
Q: How does the CiviCRM version relate to PHP platform support?
As mentioned in End-Of-Zombies: PHP 5.3 and 5.4, PHP upstream already ended support for PHP 5.3 and 5.4. We expect v5.0 will also be the first release that depends on PHP 5.5+.
Q: If releases are generally smaller, does this mean you've stopped major improvements?
Not hardly! Work on major improvements has shifted towards leap by extension. For example, overhauls to CiviMail, CiviCase, and the general UI theme have been developed as extensions. These extensions can be individually deployed and battle-tested in real environments -- without forcing everyone to transition immediately. In the future, we can provide new builds/bundles with these extensions.
Q: But I think there should be more substantive change in the process!
Grand! We appreciate concrete, actionable improvements in every layer. If you'd like to read or post some ideas, feel free to join this brainstorm or submit proposals to update the main review criteria in civicrm-dev-docs.