> All of that is what I meant when I said "everyone is using the word > "version" to mean two different things here".
Then you said I was using it wrong, which isn't the case. > Agreed, the Rails project doesn't always attain perfection. The aim though > is to make patch releases backwardly compatible. Sure, but that's not the problem, it's 1) treating patches as trivial to upgrade and 2) not being clear as to which version or patch is supported by security releases. > For the most part, and (more importantly) barring unintentional bugs, this > is precisely the intention of patch releases. Intention vs reality. Brian Cardarella's blog post is apt: http://bcardarella.com/post/628870702/a-cry-for-standardized-versioning-in-ruby-pretty This is all an aside, of course. > 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. Right now all I'm suggesting, if monkey-patches aren't provided for those who aren't at the latest patch level, is that the version that will be supported with security patches should be made clear. Before this I didn't have a reason to upgrade patch versions unless a bug affected me. If only the latest patch is supported, then I do. -- 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.
