Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

rubygem-rspec1 package is of course one possibility, but I would be 
happier if we never introduce such package. This package would be 
introduced only for backward compatibility and people (developers) would 
be never motivated to move forward. This is against one of Fedora Fs 
(First).

The biggest problem with rubygem-rspec1 is that is has not defined its 
lifespan and even if it has, there always be somebody requesting some 
compatibility packages for whatever reason. I just tried to propose to 
deprecate RSpec 1 for F17.

The time which would be spent on reviewing/maintaining the RSpec 1.x 
package would be better spent by ensuring that all packages work with 
RSpec 2.x and submitting patches upstream if necessary.


Vit



Dne 18.7.2011 09:59, TASAKA Mamoru napsal(a):
> Vít Ondruch wrote, at 07/18/2011 04:37 PM +9:00:
>> Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
>>> Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
>>>> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
>>>>> Hi guys,
>>>>>
>>>>> Since February, there are available RSpec 2.x in Fedora repositories.
>>>>> However, as of now, the main package rubygem-rspec was not migrated to
>>>>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
>>>>> if we could finish the migration to RSpec 2.x lets say in F17 time
>>>>> frame. What are your opinions? The list of packages which depends on
>>>>> RSpec 1.3 is attached bellow.
>>>>>
>>>> IMO F17 seems like a reasonable timeline for this. At that point we
>>>> might also want to provide a rubygem-rspec1-compat package for any gems
>>>> whose upstream communities haven't switched over.
>>>>
>>> Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
>>> before F-16/17 branch (i.e. 2011-07-26)?
>> Is it worth of it? We can push the change right now, but it will make
>> some packages FTBFS. Don't take me wrong, I personally +1 for this
>> change, I just wanted to give a chance to others to be prepared.
> With rubygem-rspec1 imported, I will change all packages which currently
> have "BR: rubygem(rspec)" to "BR: rubygem(rspec1)" and rebuild all those srpms.
> If those srpm don't have FTBFS issue right now, they should also succeed on
> building after this change (if they fail to build after this change, I guess
> they already had FTBFS issue)
>
>>> I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
>>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
>>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
>>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
>>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
>> Is the change in folder structure, i.e. rename from rspec to rspec1
>> really necessary? The gems don't conflicts, so it seems to me too much
>> effort for no benefit.
> Well,
> - We cannot have two "rubygem-rspec" srpm (on Fedora repository), so anyway
>     one of these should be renamed on srpm name level. With srpm renamed to
>     "rubygem-rspec1", I think reconstructuring directories and especially
>     changing rspec-1.X.gemspec to rspec"1"-1.X.gemspec would be less confusing
>     as it "matches" currently rubygem based rpms' structure
> - Anyway I think we can agree with any of the ways.
>
>>> With these rpms,
>>> - people who wants to use rspec 1 has to specify it as
>>>       (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
>>>       "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec remains as before.
>>> - people who want to use rspec 2 will specify it as
>>>       (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
>>>       /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
>>>
>>> If we can agree with these changes, I will submit these specs/srpms for
>>> review requests.
> Regards,
> Mamoru
>
>
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig