On Wed, Apr 3, 2013 at 3:22 PM, Vít Ondruch <vondruch(a)redhat.com> wrote:
Lets suppose we are in F14 timeframe and 2.3 are the newest Rails
available and lets say we have in Fedora several Rails applications using
Rails 2.3 API. They work just perfect to suit needs of their users.
Now, in F15 timeframe, Rails 3.0 were introduced. So we would like to move
the packages to Rails 3.0. But what to do with the old applications? How to
provide support for them? Note that even at this point, although Rails 2.3
are not actively developed, they are supported by upstream, so no need for
upstreams to migrate your application.
Ok, if we don't want to break anything, we have two options
1) Just introduce new package rails30 and new applications can depend on it
2) Move the rails package to Rails 3.0 and reintroduce rails23
compatibility package
That looks quite simple, but you doesn't count that what is called Ruby on
Rails is collection of 40 packages (the number vary from version to
version, but tends to increase), which would need to be re-reviewed,
although they were just perfect moment ago.
Ok, so lets say we introduce the rails23 compatibility packages (which is
IMO the better option, since the nonversioned package should always point
to newest and greatest release), we do the reviews and we possibly double
the amount of packages. We even fix all the application dependencies from
rubygem-rails to rubygem-rails23.
OK, let's skip the re-reviews. That's obviously added work.
... and now, can we be specific? No handwaving, how would parallel
installation _actually_ benefit you? How would the new system look like
and work?
Now, there comes security fix for Rails. Typically it impacts every
stable
Rails branch, i.e. it should be applied to two packages. But you already
denied me to use cherry-pick straight forward, since I am not working with
one package/repository but with two packages. So again more work then it
necessarily needed to be.
I can't see that parallel installation would help. Because there would be
one git repo for all versions? That's orthogonal to having parallel
installation of RPMs.
Yes, you might change the policy that re-reviews are not necessary,
but
anyway, you'll end up with mess of packages such as rails23, rails30,
rails31, rails32, rails40 and you lost the meaning of version. Actually
then somebody comes and he things that he doesn't need just Rails 3.0, but
he needs specifically Rails 3.0.5, so he well do another new package
rails305. You cannot stop this explosion of various versioned modules.
I can't see that parallel installation would help. We need to create and
maintain as many packages as users require in either case.
Mirek