> • 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 
RELEASING_RAILS.md is too goal-focused to accomodate a history of why the 
process is as it is.)

Thanks for the interest,


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 

Reply via email to