On Wed, Apr 3, 2013 at 3:22 PM, Vít Ondruch <vondr...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
