Re: Issues with rails right now
On 10/23/2009 11:34 AM, David Lutterkort wrote:
Hi David, and others,
I would like to take this discussion to the Ruby SIG list, as I think it
is of interest to more people then just the rubygem- and ruby-owners
I'm sorry for any duplicates this might cause, and I apologize in advance.
Let me try and summarize what we've been discussing previously, and
please do correct me if I'm wrong;
The release of an update for rubygem-rails and it's separate gems
(actionmailer, actionpack, activerecord, activeresource, activesupport,
hereonafter rails gems) has been quite the pain in the ass lately, as
there is a loop BuildRequirement dependency between the bunch of (now
separate) packages.
This has caused us (the rails gem maintainers) to reconsider packaging
these gems as separate sources, or from separate CVS modules if you
will. We agreed to try and determine whether using rails.tgz as one
source to rule them all. This part is on my plate, and all I'm going to
do is come up with a draft wiki page for all of us to shoot at. There's
problems here, such as "upstream does not always release a .tgz", and
I'm going to need to come up with ways to work around that, possibly
upstream which is more desirable then downstream.
Furthermore, we've discussed that updating rails gems would break
certain applications developed on another version of rails. See also
https://bugzilla.redhat.com/520843. In this particular case, it was
mentioned that setting the RAILS_GEM_VERSION on the RoR application
(environment) would indicate that a particular version of rails was to
be used, causing the application to fail if it were to be upgraded (by
using RPM packages), from 2.3.2 to 2.3.3 or 2.3.4. We decided to freeze
the Major.Minor.Teeny version of rails for every release. This means
that if by the time Fedora 12 is released the most recent version of
rails is 2.3.4, Fedora 12 would remain on rails-2.3.4 for the remainder
of its support cycle.
This however introduces a different problem; bugfixes in rails-2.3.4
(compared to rails-2.3.2) are not going to find their way to a
(supported) Fedora release. Hence, a set of patches needs to be shipped,
and that set will probably only grow over time while a Fedora release
nears the end of its life cycle. This, again, introduces yet another
problem.
The source for the RPM package is, say, rails-2.3.2.gem. We can patch
this source, even though obviously some work might be involved, but the
upstream version is and remains to be 2.3.2 (gem list will also show
2.3.2). In order for gem users to be able to upgrade to our new, patched
version of rails-2.3.2, we need to bump *its* version number (and not
just the RPM release). We also need to release the new, patched and
bumped rails gem *through upstream*.
We need to release through upstream, because Fedora is not allowed to
ship its own source files essentially creating a fork.
But, we cannot also not make the gem version 2.3.2.1 for the same
reasons we cannot release 2.3.4 (see bug #520843).
This is a problem we are going to have to overcome. This is, or at least
I think this is, the current discussion.
Kind regards,
Jeroen van Meeuwen
-kanarip