[PROPOSAL] Keep the X.Y.Z versioning style even for tiny security fixes

[Abdullah Esmail]

Hello there,

First I would like to thank the core team for the amazing work they've been doing.

It's amazing to see how stable and mature rails has become year over year.

With the latest release, currently 6.0.2.1, I was trying to figure out why it was 6.0.2.1 and not 6.0.3.

Looking at the guides, I did not find what the ".1" after the tiny version means.

However, I remember a few years back reading something about it being for unplanned severe security releases or something like this.

Still, personally I still feel like it's easier to increase the tiny version instead of adding an additional part.

This is just how I feel. If there is an explanation of the current versioning that I'm missing, please let me know.

Thank you so much for this amazing framework.

[Prem Sichanugrist]

Hello Abdullah,

The reason that Rails Core Team did 6.0.2.1 and not 6.0.3 because 6.0.2.1 is pretty much a forked branch out of 6.0.2 with a security patch applied on top of it.

In the past, the patched version came off a stable branch (such as 6-0-stable) and contain other changes that had unintended consequence such as uncaught regression, breaking the applications and people had to monkey-patch their Rails to get the security fix in instead of able to just upgrade to the new version.

I believe this approach is the best of both world, as if you were on 6.0.2 you can be sure that your app should still work after upgrading to 6.0.2.1 as they are pretty much the same.

Maybe we need to add more documentation about the security version to our guides, if we are missing the explanation on why we are doing it this way.

I hope this help.

-Prem

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-core/8602d8ea-f5fa-4dc9-a9b2-5cb50c991a1c%40googlegroups.com.

[Abdullah Esmail]

Thank you Prem for the explanation. I do understand it now. However, I'd kindly like to raise a point.

In the documentation for the "patch" number, it says: "Only bug fixes, no API changes, no new features. Except as necessary for security fixes."

I'm being extremely technical and specific, so bear with me :)

1. 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.
2. 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.

I know it's "just a version number" and I might be overthinking this, but for some reason this made me feel a little bit weird.

As you said, adding this to the guides might make me "at peace" (if there's anything I could do I'd be happy to provide some help).

Again, thanks for hard work.

To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.

[Matthew Draper]

> • 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

[Abdullah Esmail]

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.