v5.0: The littlest biggest increment

Opublikowane
2018-03-13 17:36
Written by

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:

  • During 2011-2016, one increment of 4.x.0 corresponded to roughly 6-10 months of work.
  • During 2016-2017, one increment of 4.7.x corresponded to roughly one month of work. (Notice a shift toward smaller units-of-work.)
  • Beginning in 2018, one increment of 5.x.0 corresponds 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:

  • If a critical regression gets into the 5.x.0, then we can more easily issue a patch-release 5.x.1.
  • If a particular 5.x merits 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.

 

FAQ

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 4.8.0 vs 5.0.0 vs 5.1804.0 vs 18.4.0 vs 33.0.0?

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 4.7.x.x?

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.

Q: Is 4.7 end-of-life? Why does my site say that 4.7 has reached the end-of-life? (ADDED, June 2018)

The in-app messaging in 4.7.x was hard-coded several years ago. For a site running the last 4.7.31, we can only display one of two messages -- that it is either up-to-date or end-of-life. Neither message is accurate or desireable -- the truth is that t 4.7.x was renamed to 5.x.

We've updated the notification system so that future messages in 5.x can be more nuanced/accurate, but for sites currently on 4.7.x we've had to make an awkward compromise. For April and May, we used the understated message; but in June, we switched to the overstated message.