hi all- upgrading some apps from 1.2.3 -->> 1.2.5 and having all kinds of issues. lot''s of functions have disappeared between versions, for instance #default_value in the pg connection adapter which breaks drysql, render_action disappearing (as indicated in past versions of course) which breaks active scaffold... etc. none of this is a big deal or hard to fix, but it did surprise me given that it''s only a minor version number which, in most circles would allow api additions and fixes, but no deletions or changes to calling signatures. what is the rails'' versioning number policy? if this is posted somewhere i didn''t have success finding it, apologies in advance. cheers. a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama --~--~---------~--~----~------------~-------~--~----~ 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 Nov 12, 2007 9:45 PM, ara.t.howard <ara.t.howard@gmail.com> wrote:> > what is the rails'' versioning number policy?If you remember, Rails 1.2.x releases where tagged from the "1.2 stable" branch. The name itself implies that there should be no breaking API changes. What happened here, IMO, is an overlook while applying bugfixes. Deprecated methods were meant to disappear in 2.0, not 1.2.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 11/12/07, ara.t.howard <ara.t.howard@gmail.com> wrote:> > hi all- > > upgrading some apps from 1.2.3 -->> 1.2.5 and having all kinds of > issues. lot''s of functions have disappeared between versions, for > instance #default_value in the pg connection adapter which breaks > drysql, render_action disappearing (as indicated in past versions of > course) which breaks active scaffold... etc. > > none of this is a big deal or hard to fix, but it did surprise me > given that it''s only a minor version number which, in most circles > would allow api additions and fixes, but no deletions or changes to > calling signatures. > > what is the rails'' versioning number policy? > > if this is posted somewhere i didn''t have success finding it, > apologies in advance. > > cheers. > > a @ http://codeforpeople.com/ > --Are you sure you are really upgrading to 1.2.5, and not 1.2.5.blah? If you are using RAILS_GEM_VERSION to set your rails version (not vendor/rails), you may actually be using the 2.0 prerelease if you aren''t careful. There was a fix that went into 1.2.5 to boot.rb to fix this issue... - 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 11/12/07, Rob Sanheim <rsanheim@gmail.com> wrote:> Are you sure you are really upgrading to 1.2.5, and not 1.2.5.blah? > If you are using RAILS_GEM_VERSION to set your rails version (not > vendor/rails), you may actually be using the 2.0 prerelease if you > aren''t careful. > > There was a fix that went into 1.2.5 to boot.rb to fix this issue...Yes. First, see if you have a gem rails-1.2.5.xxxx installed on your machine. If you do, then you probably have a problem. To confirm, do a ''p $:'' at the end of environment.rb. If you see that gem on your load path, then that''s definitely the problem. Uninstall the offending beta gem, then upgrade to the real 1.2.5 (not 1.2.5.xxxx), and also update your boot.rb using ''rake rails:update:configs'' to avoid the problem in the future. FYI, this ticket [ http://dev.rubyonrails.org/ticket/10074 ] seeks to avoid this issue in the future, and seems to have helped, since the new beta gem is 1.99.0. I think 2.0.0.<revision> would have been a better choice myself, but oh well :) -- 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 11/12/07, Chad Woolley <thewoolleyman@gmail.com> wrote:> > On 11/12/07, Rob Sanheim <rsanheim@gmail.com> wrote: > > Are you sure you are really upgrading to 1.2.5, and not 1.2.5.blah? > > If you are using RAILS_GEM_VERSION to set your rails version (not > > vendor/rails), you may actually be using the 2.0 prerelease if you > > aren''t careful. > > > > There was a fix that went into 1.2.5 to boot.rb to fix this issue... > > Yes. First, see if you have a gem rails-1.2.5.xxxx installed on your > machine. If you do, then you probably have a problem. To confirm, do > a ''p $:'' at the end of environment.rb. If you see that gem on your > load path, then that''s definitely the problem. > > Uninstall the offending beta gem, then upgrade to the real 1.2.5 (not > 1.2.5.xxxx), and also update your boot.rb using ''rake > rails:update:configs'' to avoid the problem in the future. > > FYI, this ticket [ http://dev.rubyonrails.org/ticket/10074 ] seeks to > avoid this issue in the future, and seems to have helped, since the > new beta gem is 1.99.0. I think 2.0.0.<revision> would have been a > better choice myself, but oh well :)Well then it would''ve loaded in front of 2.0.0, right? I think that''s why 1.99 was chosen. -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.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 -~----------~----~----~----~------~----~------~--~---
> > what is the rails'' versioning number policy? > > If you remember, Rails 1.2.x releases where tagged from the "1.2 stable" > branch. The name itself implies that there should be no breaking API > changes. What happened here, IMO, is an overlook while applying bugfixes. > Deprecated methods were meant to disappear in 2.0, not 1.2.x ...The intention with the stable releases is that no part of our public api (the stuff documented in the api docs) breaks. If there are changes which have broken that, let us know by opening a ticket or mailing this list, we''re already intending on another 1.2.x release to fix an associations regression introduced when fixing a performance issue with unsaved associations. Plugins *will* break if they''re messing with private methods, there''s no way we can guess what private / implementation methods are being overridden. In the event that we keep busting a non-intrusive plugin, we can look at providing a stable API which will remain unbroken during a point release. The changes like render_action disappearing only happened in trunk, so you''re obviously running the ''fake'' 1.2.x releases which are now labeled more clearly. -- 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 11/12/07, Rick Olson <technoweenie@gmail.com> wrote:> > > FYI, this ticket [ http://dev.rubyonrails.org/ticket/10074 ] seeks to > > avoid this issue in the future, and seems to have helped, since the > > new beta gem is 1.99.0. I think 2.0.0.<revision> would have been a > > better choice myself, but oh well :) > > Well then it would''ve loaded in front of 2.0.0, right? I think that''s > why 1.99 was chosen.Yes, but I proposed incrementing the "TINY" component in the "real" release - so you''d get 2.0.1 as the first final release that you push to RubyForge. This would have the benefit of making the beta release versions more indicitive of what the actual release will be. e.g., 2.0.0.<x> seems closer to 2.0.1 than 1.99.<x> is to 2.0.0. When you refer to "2.0 RC1", it makes sense for the version to start with "2.0". As long as you aren''t stuck on having the final release have a zero TINY component, this works fine. I describe this in more detail in the ticket. Regardless, they versioning is now at least sequential with regard to branch/trunk chronology, and doesn''t mix branch and trunk versions sequentially, so that''s the main point. Thanks for making the change! -- 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 Nov 12, 2007, at 5:35 PM, Michael Koziarski wrote:> > The changes like render_action disappearing only happened in trunk, so > you''re obviously running the ''fake'' 1.2.x releases which are now > labeled more clearly.bingo. thanks all - problem solved. i''m still pretty unclear about the versioning policy though (arbitrary svn tags which are not embeded in gems aside). i was after something a bit more concrete such as http://rubygems.org/read/chapter/7#page26 or, quoting from http://www.gnu.org/software/libtool/manual.html#Libtool-versioning " So, libtool library versions are described by three integers: current The most recent interface number that this library implements. revision The implementation number of the current interface. age The difference between the newest and oldest interfaces that this library implements. In other words, the library implements all the interface numbers in the range from number current - age to current. If two libraries have identical current and age numbers, then the dynamic linker chooses the library with the greater revision number. " and the comments on a 1.99 version that is not backward compatible with 1.2.x make me wonder: what is this.that.andthat supposed to mean in a rails version tag *exactly* ?? kind regards. a @ http://codeforpeople.com/ -- share your knowledge. it''s a way to achieve immortality. h.h. the 14th dalai lama --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> and the comments on a 1.99 version that is not backward compatible > with 1.2.x make me wonder: what is > > this.that.andthatI can''t help with a specific definition or a URL to point you at, but in practice code which used documented apis on 1.2.x should work on 1.2.y for all y > x. It''s intended to be a drop in replacement, and when we introduce regressions we tend to fix them with a follow up release. The choice between calling something 1.5 or 2.0 is a little more vague, but basically don''t expect a drop in upgrade if the major number changes. The most important thing is to pay attention to the deprecation warnings you receive, the next major release will have that code removed. As for 1.99, it''s just a way to say ''not quite 2.0'', it''s not intended for production use and has no backwards or forwards compatibility guarantees, though obviously we hope it works just fine :).> supposed to mean in a rails version tag *exactly* ?? > > kind regards. > > a @ http://codeforpeople.com/ > -- > share your knowledge. it''s a way to achieve immortality. > h.h. the 14th dalai lama > > > > > >-- 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 Nov 12, 2007, at 7:53 PM, Michael Koziarski wrote:> I can''t help with a specific definition or a URL to point you at, but > in practice code which used documented apis on 1.2.x should work on > 1.2.y for all y > x. It''s intended to be a drop in replacement, and > when we introduce regressions we tend to fix them with a follow up > release. > > The choice between calling something 1.5 or 2.0 is a little more > vague, but basically don''t expect a drop in upgrade if the major > number changes. The most important thing is to pay attention to the > deprecation warnings you receive, the next major release will have > that code removed.fair enough - that''s enough info to know which upgrades are ok to do on a friday night and which are not ;-) thx a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> upgrading some apps from 1.2.3 -->> 1.2.5 and having all kinds of > issues. lot''s of functions have disappeared between versions, for > instance #default_value in the pg connection adapter which breaks > drysql, render_action disappearing (as indicated in past versions of > course) which breaks active scaffold... etc.Public method changes within a major version are usually bugs. If you find any, please do report or even fix it. Private methods are considered implementation details and can be changed in any version. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---