On Wed, Apr 23, 2014 at 03:58:30PM +0200, Cédric Boutillier wrote: > Hi! > > On Tue, Apr 22, 2014 at 04:20:02PM -0300, Miguel Landaeta wrote: > > Hi folks, > > > I'm packaging ruby-vcr and I noticed all the unit tests were failing > > badly. > > > After reviewing why I found that package relies on rspec '>= 3.0.0.beta1'. > > > So, I was wondering what are the plans for RSpec in Debian for jessie. > > > I was reading about compatibility with 2.x but is not totally clear > > to me if it's going to be fully backward compatible or not. AIUI, yes, > > it's going to be compatible but I would appreciate comments from more > > experienced users and developers in the know of this tool. > > > * Is anybody working to package 3.0 release? > > > * Do you plan to have a separate package for it? > > I read that RSpec 3 will be compatible with the non-deprecated features > in RSpec 2.14. > > http://myronmars.to/n/dev-blog/2013/07/the-plan-for-rspec-3 > > However, we see a lot of deprecation warning in packages > using the RSpec framework right now, and I am pretty sure that replacing > the current rspec packages with version 3 will result in dozens of > packages FTBFSing. > > Therefore, I would propose to have a ruby-rspec3 package (or a series of > ruby-rspec3-* packages). We would need then to either: > - make them conflict with the current ruby-rspec (for installation path > reasons) > - or install them in another path, and patch all packages using RSpec3. > > I think that for jessie, we can go for the second strategy, since I > don't think that we will have many packages running RSpec3. > In the mean time, we can try to update the rspec2 packages to the 2.99 > version, which will list all the deprecation warning for stuff dropped > in RSpec3. > We can use our "free time" during the freeze to send patches upstream to > update their test suite for RSpec 3, and have all our packages ready for > Jessie + 1. I think we should avoid adding versioned packages like ruby-rspec3 at all costs. I would rather break packages using features that are deprecated on rspec 2 now than having to support rspec2 for jessie+1. I think it would be a better use of everyone's time to: - upload rspec3 as a new upstream of ruby-rspec now¹ and block it from going to testing (OR do it all on experimental and leave unstable and testing alone for now) - do a test rebuild to catch the offenders - start fixing and reporting bugs upstream. ¹ we could take the opportunity to make rspec a single source package getting the source from github instead of getting individual gems from rubygems.org (or not, whatever is easier for who will do the work) -- Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: Digital signature