Issues with rails right now

[Jeroen van Meeuwen]

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