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.
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 …
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
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.
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!
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
"
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* ??
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 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 :).
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.
