Re: [Rails-core] [PROPOSAL] Keep the X.Y.Z versioning style even for tiny security fixes

[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.

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.

Re: [Rails-core] [PROPOSAL] Keep the X.Y.Z versioning style even for tiny security fixes

[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


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

Re: [Rails-core] [PROPOSAL] Keep the X.Y.Z versioning style even for tiny security fixes

[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.


On Tuesday, December 24, 2019 at 5:45:00 PM UTC+3, Prem Sichanugrist wrote:
>
> 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
>
>
>
> On Tue, Dec 24, 2019 at 11:10 PM Abdullah Esmail  > wrote:
>
>> 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.
>>
>> -- 
>> 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 rubyonra...@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
>>  
>> 
>> .
>>
>

-- 
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/9c8d0ab3-01a8-41d8-acb1-85bb18d11d02%40googlegroups.com.

Re: [Rails-core] [PROPOSAL] Keep the X.Y.Z versioning style even for tiny security fixes

[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



On Tue, Dec 24, 2019 at 11:10 PM Abdullah Esmail 
wrote:

> 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.
>
> --
> 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/8602d8ea-f5fa-4dc9-a9b2-5cb50c991a1c%40googlegroups.com
> 
> .
>

-- 
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/CAG_6CsPPfAZGN%3D1rNR60mOMzA%3DCZJZtGHZWF-u4Z5TBahuV9hQ%40mail.gmail.com.