Extract its into external rspec-its gem

[myronmarston]

• Build rspec-its gem
• Remove its from rspec-core's master branch
• Add deprecation notice to rspec-core's 2.99 branch

[palfvin]

Per our email exchange, I'm up for taking this on.

[myronmarston]

Sounds good. I just created a repo for you:

https://github.com/rspec/rspec-its

You should have commit access.

As far as next steps, see the checklist listed on this issue above. It might be useful to peruse these to see how we've done it for rspec-collection_matchers:

• https://github.com/rspec/rspec-collection_matchers/commits/master
• Remove have(n).items matchers rspec-expectations#293
• Deprecates the have, have_at_least, have_at_most matchers rspec-expectations#309

Let us know if you have any concerns or questions.

Thanks!

[palfvin]

Thanks for getting me set up, Myron.
On Sep 23, 2013 1:37 PM, "Myron Marston" notifications@github.com wrote:

Sounds good. I just created a repo for you:

https://github.com/rspec/rspec-its

You should have commit access.

As far as next steps, see the checklist listed on this issue above. It
might be useful to peruse these to see how we've done it for
rspec-collection_matchers:

• https://github.com/rspec/rspec-collection_matchers/commits/master
• Remove have(n).items matchers rspec-expectations#293Remove have(n).items matchers rspec-expectations#293
• Deprecates the have, have_at_least, have_at_most matchers rspec-expectations#309Deprecates the have, have_at_least, have_at_most matchers rspec-expectations#309

Let us know if you have any concerns or questions.

Thanks!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1083#issuecomment-24952256
.

[palfvin]

Myron, I haven't transferred anything to rspec/rspec-its or generated any pull requests, but I have the rspec-core changes and rspec-its set up and tests in my own repository. Do you want to review them there first? A lot of the tools stuff is new for me, including any non-trivial use of github, so I wanted to make my initial mistakes as locally as possible.

The actual extraction seemed trivial, though, so unless I missed something, hopefully there's not a lot to worry about in that regard. Let me know.

[palfvin]

Just reread your 3.0 release plan and realized that I didn't address the 2.99 needs. Will do that.

[myronmarston]

Myron, I haven't transferred anything to rspec/rspec-its or generated any pull requests, but I have the rspec-core changes and rspec-its set up and tests in my own repository. Do you want to review them there first? A lot of the tools stuff is new for me, including any non-trivial use of github, so I wanted to make my initial mistakes as locally as possible.

Just submit PRs to the main repos, please. Do them one at a time: we're not going to consider removing its from rspec-core until the gem is ready, and we don't need the deprecation warning in 2.99 until its removed from master.

[palfvin]

Just submitted rspec/rspec-its#1 for step 1 of creating the gem.

[palfvin]

@JonRowe I'm trying to test against rspec 2.99 as you indicated, but I'm running into trouble trying to get a 2.99 reference to work. If I specify each of the core gems individually in my Gemfile, using the 2-99-maintenance branch, then it works fine. But I specify that same branch for the rspec meta gem, I got an error that it can't resolve the dependency on the 2.99.0.pre components. It's not a big deal, obviously, but I was just curious if I was missing something.

[JonRowe]

Use the 3 gems individually. I don't think there is one for the meta gem.

[myronmarston]

Looks like this is done. Closing.

[palfvin]

@myronmarston Any guidance on how to handle Relish for this extracted gem? Do you want to limit the RSpec publisher to just the gems supported by the core team? If so, do you have any suggestions for what to name the publisher I create for this purpose? Should I just use my own name?

More generally, can you rationalize the use of the rspec github account for this gem when it's not used for, say, xavier's rspec-fire gem? Will this gem have some special status going forward vs. any other gem created to complement the RSpec gems maintained by the core team?

Finally, as I was checking around for other, non-core RSpec gems, I encountered rspec-api-documentation, which seems to have violated the rubygems naming convention involving use of dashes and underscores as covered in http://guides.rubygems.org/name-your-gem/ Is this anything you think is worth trying to raise with the author?

[myronmarston]

Any guidance on how to handle Relish for this extracted gem?

That's completely up to you as maintainer of this gem.

Do you want to limit the RSpec publisher to just the gems supported by the core team?

Yes.

If so, do you have any suggestions for what to name the publisher I create for this purpose? Should I just use my own name?

That's what most people do.

More generally, can you rationalize the use of the rspec github account for this gem when it's not used for, say, xavier's rspec-fire gem? Will this gem have some special status going forward vs. any other gem created to complement the RSpec gems maintained by the core team?

rspec-its has been extracted from gems maintained by the core team. We thought it made sense to make it part of the rspec account on github so that it's clear to others that it is in some sense "blessed" by the core team. It gives it a bit more "legitimacy", if that makes sense.

Finally, as I was checking around for other, non-core RSpec gems, I encountered rspec-api-documentation, which seems to have violated the rubygems naming convention involving use of dashes and underscores as covered in http://guides.rubygems.org/name-your-gem/ Is this anything you think is worth trying to raise with the author?

Nope. It's not my job or anyone else's to police how folks name their gems.