> • As long as you're releasing a new version of software, there is a risk that > something somewhere will break. It's hard (if not impossible) to guarantee > that the software will run as expected after an upgrade, even if the change > is a single line of code. > • According to the description for the patch version number, upgrading from > rails A.B.C to A.B.(C+N) should work as expected unless it's absolutely > necessary to break things due to security fixes. > Based on this, in this case, I think doing 6.0.3 or 6.0.2.1 should > technically mean the same thing.
This is fairly true — all patch releases are expected to be compatible [though a larger collection of bug fixes will naturally contain a greater number of minor, intentional, “the previous behaviour was a bug”, behaviour changes than a single-patch security release]. The stronger issue solved by the four-part version number is one of communication around bug fixes and patch releases: Thanks to the extra version number, you can be confident that if a commit appears on the 6-0-stable branch, then 6.0.(current+1) will contain that change. Previously, when we used the patch version for security releases, it was impossible to know at merge time (or any time before the next patch release) which version number would be the first to contain the change. And it’s just generally more difficult to discuss: the version number is the only available name for a given upcoming release, yet a security fix could appear at any time and ’steal’ that name, meaning all conversations about 6.0.3 were actually talking about the release that will now be numbered 6.0.4 (assuming a further security release doesn’t intervene). Finally, the four-part style means we can make a security release at any time: if the highest published versions are 6.0.2 and 6.0.3.rc1, there is no reasonable choice of three-part version number that won’t create a mess for some people: either the security release is forced to include the bug fixes from the rc, or we release a higher-numbered version [either 6.0.3 or 6.0.4] that doesn’t contain changes that were in the lower-versioned rc1. (Plus if we use 6.0.3, it’s different from the rc; if we use 6.0.4, we’ve skipped a final release number, leaving an odd hole in the version history.) This would historically mean patch releases could be held up waiting on a security release to happen first. So, sorry it’s caused you discomfort, but no, it’s really not easier to stick to x.y.z — we adopted this system because it solved real problems. I’m not sure whether this reasoning has ever been documented anywhere; if not, and you can find a suitable place to fold it in, a PR would be great. (I’d be wary of dropping it into the middle of the maintenance policy, though.. that focuses on how to _read_ the version, so a brief mention that the fourth number can exist would be suitable, but most of the above rambling is about a level of _why_ that would be distracting/irrelevant there. I think even RELEASING_RAILS.md is too goal-focused to accomodate a history of why the process is as it is.) Thanks for the interest, Matthew -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-core/F71E9D18-3A45-4C35-AF85-72D00C8D0E13%40trebex.net.
