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 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/e7e0058d-4a4a-4334-ab31-e7c73bba84c3%40googlegroups.com.
