> > ---------- Forwarded message ---------- > From: fowlduck <[email protected]> > Date: Thu, Feb 10, 2011 at 10:55 AM > Subject: Re: Security Patches and Rails 2.3.11/3.0.4 > To: Jason King <[email protected]> > > > > I think you're misunderstanding what the last number in 2.3.2, 2.3.4 etc. > > means. And everyone is using the word "version" to mean two different > > things here. > > > > The *versions* of Rails supported are 2.3 and 3.0 (although José says 2.1 > > and 2.2 as well) - which is why both had a patch release with the > security > > patches. In the proper sense of the word, "upper-case V" Version if you > > like, 2.3.5 is not a *version* of Rails, it's patch release 5 of version > > 2.3. > > > > 2 = Major version > > 3. = Minor version > > 5 = Patch number > > 1) Semantic Versioning calls them versions and it's part of the > version number. > > 2) The post on the new releases disagrees with your usage of the term: > http://weblog.rubyonrails.org/2011/2/8/new-releases-2-3-11-and-3-0-4 > > 3) > http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails > calls what you're calling "versions," the 2.3 and 3.0 "release > series." This makes it unclear which patches are supported. >
All of that is what I meant when I said "everyone is using the word "version" to mean two different things here". > 4) On top of it all, rails patch versions often introduce backwards > incompatible changes, so they're closer to minor versions than > patches. > Agreed, the Rails project doesn't always attain perfection. The aim though is to make patch releases backwardly compatible. > So if you want to get into semantics, I think it's clear that they're > versions or at least called versions. The treatment of them as simple > patches that are trivial to upgrade (meaning no changes to your app) > is unfounded. > For the most part, and (more importantly) barring unintentional bugs, this is precisely the intention of patch releases. Anyway, what are you suggesting? To maintain a security patch release on top of each of the releases? That will just shift the problem to the next level - ie. there'll *still* be people who want the 2.3.5.2 patch but don't want 2.3.5.1 because it breaks something they rely on (less likely than now, yes, but impossible to eliminate altogether). People will still need to resort to just pulling the patch and applying it to a vendored Rails. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
