Thanks Matthew, this actually is starting to make more sense.
I might add a PR for your consideration in the maintenance policy. 
Something brief and clear.

On Tuesday, December 24, 2019 at 9:27:36 PM UTC+3, matthewd wrote:
> > • 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 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 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 view this discussion on the web visit

Reply via email to