Hi, I''m upgrading to Rails 2.1 pre-release (2.0.991). The problem with this version number is when people use pessimistic version constraint (like me): RAILS_GEM_VERSION = ''~> 2.0.2'' I have explicitly defined that I want my app to stay on the "2.0.x" stream, but with the "2.0.991" hack they are going to update to Rails 2.1. Version numbers (major, minor, tiny) have solid semantics in Rails software and this hack with pre-releases is clearly a violation of them. I just wanted to bring this to your attention, I don''t really have an idea for an alternative to releasing RC software as "2.1.x" --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, May 12, 2008 at 1:29 PM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> Hi, I'm upgrading to Rails 2.1 pre-release (2.0.991). > > The problem with this version number is when people use pessimistic version > constraint (like me): > > RAILS_GEM_VERSION = '~> 2.0.2' > > I have explicitly defined that I want my app to stay on the "2.0.x" stream, > but with the "2.0.991" hack they are going to update to Rails 2.1. > > Version numbers (major, minor, tiny) have solid semantics in Rails software > and this hack with pre-releases is clearly a violation of them. I just > wanted to bring this to your attention, I don't really have an idea for an > alternative to releasing RC software as "2.1.x"There is no viable workaround, as far as I can tell. Use a stronger constraint (= 2.0.2) and change it when you upgrade Rails. jeremy --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
2008/5/12 Jeremy Kemper <jeremy@bitsweat.net>:> On Mon, May 12, 2008 at 1:29 PM, Mislav Marohnić > <mislav.marohnic@gmail.com> wrote: > > Version numbers (major, minor, tiny) have solid semantics in Rails software > > and this hack with pre-releases is clearly a violation of them. I just > > wanted to bring this to your attention, I don't really have an idea for an > > alternative to releasing RC software as "2.1.x" > > There is no viable workaround, as far as I can tell. Use a stronger > constraint (= 2.0.2) and change it when you upgrade Rails.This IS a 2.1 branch build, so it should have a 2.1.x.x version. Releasing it with a 2.0.anything version is just wrong, because it is not from the 2.0 branch. The workaround (as I've mentioned in an earlier thread) is to use the fourth component for release candidates, such as: 2.1.0.xxx Then, when you cut the final release, call it: 2.1.1 Yes, some people may be disturbed that the initial public release of a branch does not end in zero, but so what? The third component is just signifying that this is some incremental release of the 2.1 branch - and it actually makes sense that it is not zero, since there have been previous Release Candidates of the 2.1 branch. In any case, this semantic nit of not having the initial public release release end in zero is insignificant and causes no real problems. On the other hand, giving a 2.1 branch release a version of 2.0 does cause real problems when trying to use RubyGems versions as intended, as Mislav notes. -- Chad --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Jeremy: how about this in boot.rb -- http://pastie.org/195736 2008/5/12 Jeremy Kemper <jeremy@bitsweat.net>:> On Mon, May 12, 2008 at 1:29 PM, Mislav Marohnić > <mislav.marohnic@gmail.com> wrote: > > Hi, I'm upgrading to Rails 2.1 pre-release (2.0.991). > > > > The problem with this version number is when people use pessimistic > version > > constraint (like me): > > > > RAILS_GEM_VERSION = '~> 2.0.2' > > > > I have explicitly defined that I want my app to stay on the "2.0.x" > stream, > > but with the "2.0.991" hack they are going to update to Rails 2.1. > > > > Version numbers (major, minor, tiny) have solid semantics in Rails > software > > and this hack with pre-releases is clearly a violation of them. I just > > wanted to bring this to your attention, I don't really have an idea for > an > > alternative to releasing RC software as "2.1.x" > > There is no viable workaround, as far as I can tell. Use a stronger > constraint (= 2.0.2) and change it when you upgrade Rails. > > jeremy > > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> In any case, this semantic nit of not having the initial public > release release end in zero is insignificant and causes no real > problems. On the other hand, giving a 2.1 branch release a version of > 2.0 does cause real problems when trying to use RubyGems versions as > intended, as Mislav notes.The beta gems are never sent to rubyforge, I think you''re overstating the issues here. 99% of rails'' users will never even notice this has happened. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, May 12, 2008 at 2:03 PM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> Jeremy: how about this in boot.rb -- http://pastie.org/195736I don't think that is good. I don't want boot.rb hacking a gem version that I've already specified. This will break scenarios where a specific version of the Rails has already been activated, via preinitializer.rb, for example. This will tell gem to try and load a different version than was already specified and activated, which will raise an exception. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, May 12, 2008 at 2:05 PM, Michael Koziarski <michael@koziarski.com> wrote:> > > In any case, this semantic nit of not having the initial public > > release release end in zero is insignificant and causes no real > > problems. On the other hand, giving a 2.1 branch release a version of > > 2.0 does cause real problems when trying to use RubyGems versions as > > intended, as Mislav notes. > > The beta gems are never sent to rubyforge, I think you''re overstating > the issues here. 99% of rails'' users will never even notice this has > happened.OK, maybe :) However, I think you are ignoring the issue that giving a 2.1 branch build a version of 2.0.anything is just wrong. 1% of Rails users is still more than a few users, and to have Rails actively doing things that go against RubyGems standards and breaks stuff is not a good thing. Especially if there is a workaround that causes no actual failures, and solves a problem which does cause actual failures. -- Chad -- Chad --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
2008/5/12 Chad Woolley <thewoolleyman@gmail.com>:> 2008/5/12 Jeremy Kemper <jeremy@bitsweat.net>: >> On Mon, May 12, 2008 at 1:29 PM, Mislav Marohnić >> <mislav.marohnic@gmail.com> wrote: >> > Version numbers (major, minor, tiny) have solid semantics in Rails software >> > and this hack with pre-releases is clearly a violation of them. I just >> > wanted to bring this to your attention, I don't really have an idea for an >> > alternative to releasing RC software as "2.1.x" >> >> There is no viable workaround, as far as I can tell. Use a stronger >> constraint (= 2.0.2) and change it when you upgrade Rails. > > This IS a 2.1 branch build, so it should have a 2.1.x.x version. > Releasing it with a 2.0.anything version is just wrong, because it is > not from the 2.0 branch. > > The workaround (as I've mentioned in an earlier thread) is to use the > fourth component for release candidates, such as: > > 2.1.0.xxx > > Then, when you cut the final release, call it: > > 2.1.1 > > Yes, some people may be disturbed that the initial public release of a > branch does not end in zero, but so what? The third component is just > signifying that this is some incremental release of the 2.1 branch - > and it actually makes sense that it is not zero, since there have been > previous Release Candidates of the 2.1 branch. > > In any case, this semantic nit of not having the initial public > release release end in zero is insignificant and causes no real > problems. On the other hand, giving a 2.1 branch release a version of > 2.0 does cause real problems when trying to use RubyGems versions as > intended, as Mislav notes.+1 I'd also like to be working with a 2.1 that's actually 2.1.x, not 2.0.x. Assaf> > -- Chad > > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 12 May 2008, at 22:30, Chad Woolley wrote:> > > 1% of Rails users is still more than a few users, and to have Rails > actively doing things that go against RubyGems standards and breaks > stuff is not a good thing. Especially if there is a workaround that > causes no actual failures, and solves a problem which does cause > actual failures. >It might be more than 1% given that aptana was silently adding gems.rubyonrails.org to people''s gem sources (and re-adding it when people removed it), although those people were already picking up the edge rails gems (2.0.2.xxxx) and suffering accordingly. Fred --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, May 12, 2008 at 2:30 PM, Chad Woolley <thewoolleyman@gmail.com> wrote:> > On Mon, May 12, 2008 at 2:05 PM, Michael Koziarski > <michael@koziarski.com> wrote: > > > > > In any case, this semantic nit of not having the initial public > > > release release end in zero is insignificant and causes no real > > > problems. On the other hand, giving a 2.1 branch release a version of > > > 2.0 does cause real problems when trying to use RubyGems versions as > > > intended, as Mislav notes. > > > > The beta gems are never sent to rubyforge, I think you''re overstating > > the issues here. 99% of rails'' users will never even notice this has > > happened. > > OK, maybe :) > > However, I think you are ignoring the issue that giving a 2.1 branch > build a version of 2.0.anything is just wrong. > > 1% of Rails users is still more than a few users, and to have Rails > actively doing things that go against RubyGems standards and breaks > stuff is not a good thing. Especially if there is a workaround that > causes no actual failures, and solves a problem which does cause > actual failures.By "just wrong" you mean it violates RubyGems'' versioning policy. It''s a tradeoff so we can release 2.1, not 2.1.1. Labeling 2.0.991 as "just wrong" prohibits any reasonable compromise. We accept the violation so we can have a clean release version. Consider it an amendment to RubyGems'' policy; call it Rails'' versioning policy; redefine "just wrong." Best, jeremy --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On May 12, 2008, at 5:44 PM, Frederick Cheung wrote:> On 12 May 2008, at 22:30, Chad Woolley wrote: >> 1% of Rails users is still more than a few users, and to have Rails >> actively doing things that go against RubyGems standards and breaks >> stuff is not a good thing. Especially if there is a workaround that >> causes no actual failures, and solves a problem which does cause >> actual failures. >> > It might be more than 1% given that aptana was silently adding > gems.rubyonrails.org to people''s gem sources (and re-adding it when > people removed it), although those people were already picking up the > edge rails gems (2.0.2.xxxx) and suffering accordingly. > > FredOr Rails could adopt a 2.[02468].x is Stable, 2.[13579].x is "edge" and avoid all the trouble. If Ruby (and many others) can have the even-numbered point releases be the stable and the odd-numbered be the "experimental", why couldn''t Rails? As quickly as the first post-release patches have come out the last few times, it would be 2.x.(y+1) regardless of whether y starts as 0 or 1. -Rob --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, May 12, 2008 at 11:51 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote:> > We accept the violation so we can have a clean release version. > Consider it an amendment to RubyGems'' policy; call it Rails'' > versioning policy; redefine "just wrong."I can accept that. But can we modify boot.rb as in my pastie then? @Chad: I didn''t understand what did you say the drawback would be? --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, May 12, 2008 at 2:57 PM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> @Chad: I didn't understand what did you say the drawback would be?Whatever self.gem_version returns in boot.rb is what should be used. load_rails_gem should not attempt to load a different version, because it will fail if the prior version has already been loaded. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
2008/5/13 Chad Woolley <thewoolleyman@gmail.com>:> On Mon, May 12, 2008 at 2:57 PM, Mislav Marohnić > <mislav.marohnic@gmail.com> wrote: > > @Chad: I didn't understand what did you say the drawback would be? > > Whatever self.gem_version returns in boot.rb is what should be used. > load_rails_gem should not attempt to load a different version, because > it will fail if the prior version has already been loaded.You are right, but the hack could be easily moved inside self.gem_version. I don't think of this as dangerous messing with specified versions, I'd like to think of this as safety belt against RCs. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
As far as conveyed intention something.99 tells me clearly that''s
almost something. Since there are no even/odd releases as of this
writing I am +1 on having a clean version 2.1 stable.
Given the current versioning schema people cannot expect stable
releases using gem sources and wildcards. And if you run edge/RCs I am
sure you are able to understand the current convention and its
implications ("you" being generic).
The right fix in my view, if needed anyway, would be to introduce
odd/even releases in the future.
--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
On Tue, May 13, 2008 at 11:11 AM, Xavier Noria <fxn@hashref.com> wrote:> As far as conveyed intention something.99 tells me clearly that''s > almost something.Heh, I mean something + 1. Looks it is less clear to me when using words :-). --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, May 12, 2008 at 5:54 PM, Rob Biedenharn <Rob.Biedenharn@gmail.com> wrote:> > Or Rails could adopt a 2.[02468].x is Stable, 2.[13579].x is "edge" > and avoid all the trouble. If Ruby (and many others) can have the > even-numbered point releases be the stable and the odd-numbered be the > "experimental", why couldn''t Rails?Well Ruby used to use that convention, but Matz did away with it with 1.9, Ruby versioning now has x.y.0 as "experimental/development" and x.y.[123456789] as "production". Ruby 1.9.1 (whenever it happens) will be the first production version of 1.9. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, May 13, 2008 at 5:19 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:> Well Ruby used to use that convention, but Matz did away with it with > 1.9, Ruby versioning now has x.y.0 as "experimental/development" and > x.y.[123456789] as "production". Ruby 1.9.1 (whenever it happens) > will be the first production version of 1.9.Which seems to be pretty close to what I am proposing, no? --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---