[Rails-core] Re: versioning strategy

2007-11-13 Thread DHH
> 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) whic

[Rails-core] Re: versioning strategy

2007-11-12 Thread ara.t.howard
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 regressio

[Rails-core] Re: versioning strategy

2007-11-12 Thread Michael Koziarski
> 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 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 i

[Rails-core] Re: versioning strategy

2007-11-12 Thread ara.t.howard
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 v

[Rails-core] Re: versioning strategy

2007-11-12 Thread Chad Woolley
On 11/12/07, Rick Olson <[EMAIL PROTECTED]> 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. would have been a > > better choice myself, but oh well

[Rails-core] Re: versioning strategy

2007-11-12 Thread Michael Koziarski
> > 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

[Rails-core] Re: versioning strategy

2007-11-12 Thread Rick Olson
On 11/12/07, Chad Woolley <[EMAIL PROTECTED]> wrote: > > On 11/12/07, Rob Sanheim <[EMAIL PROTECTED]> 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 th

[Rails-core] Re: versioning strategy

2007-11-12 Thread Chad Woolley
On 11/12/07, Rob Sanheim <[EMAIL PROTECTED]> 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 t

[Rails-core] Re: versioning strategy

2007-11-12 Thread Rob Sanheim
On 11/12/07, ara.t.howard <[EMAIL PROTECTED]> 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 di

[Rails-core] Re: versioning strategy

2007-11-12 Thread Mislav Marohnić
On Nov 12, 2007 9:45 PM, ara.t.howard <[EMAIL PROTECTED]> 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