WIP: sketch out blog post for 3.3 release.

[myronmarston]

This is the start of the blog post announcing the 3.3 release.

@cupakromer -- I haven't followed rspec-rails dev close enough to know what's notable there. Any suggestions for what, if anything, we should highlight about rspec-rails 3.3?

@rspec/rspec -- thoughts on the items I highlighted in the "Notable Changes" section? Is there anything important I missed?

[cupakromer]

Any suggestions for what, if anything, we should highlight about rspec-rails 3.3?

These two are notable:

• Add support for PATCH to route specs created via scaffold. (Igor Zubkov, #1336)
• Add support for ActiveJob specs as standard RSpec::Rails::RailsExampleGoups via both :type => :job and inferring type from spec directory spec/jobs. (Gabe Martin-Dempesy, #1361)

[myronmarston]

These two are notable:

Thanks. Are you up for writing up a short blurb explaining those?

[JonRowe]

I think the any_instance changes to the verifying double hooks are in 3.3, even if they're not quite working with rspec-rails as we'd expect just yet?

[myronmarston]

I think the any_instance changes to the verifying double hooks are in 3.3, even if they're not quite working with rspec-rails as we'd expect just yet?

Doesn't seem worth highlighting, IMO, for a couple reasons:

• It's not yet having the intended affect in rspec-rails, as you said, so I'm not sure what we'd say. "RSpec-Rails issue partally fixed"? That's not very notable. Until it has the intended affect in rspec-rails it's not really user facing, right?
• I don't really want to highlight any_instance since we don't want to further encourage its use.

[JonRowe]

Fair enough, it might be worth noting that it causes the callback to be called before partial doubles now, which might be useful outside rspec-rails.

[myronmarston]

I've written about 2/3 of the blog post. More to come, but if anyone wants to review it, have at it.

I'm hoping to release today or tomorrow.

[JonRowe]

s/3.2/3.3

[JonRowe]

Looking good so far!

[myronmarston]

OK, I updated the rest of the notable changes. @cupakromer, can you confirm what I wrote sounds good? I based the statement that we've supported patch since 2.14 on rspec/rspec-rails@ 0039c84698a7a45995e6eff7ff5b5cce000b86da. For :type => :job one I wasn't sure what to say. As far as I can see rspec/rspec-rails#1361 just wires up an empty example group module that doesn't actually contain any functionality, right? Or is there actually some new feature it provides for the user that I'm not seeing?

[dchelimsky]

Wow, folks, these are some really impressive improvements. Congrats to all involved!

I realize I might be too late to the party, but a couple of suggestions having read the post in its current state:

I think it would help to mention (even if it might seem obvious) the fact that you can set meta[:aggregate_failures] = true globally and then override it for individual examples to false. That section implies that, but is not specific about it.

This is almost assuredly too late, but I think it would be easier to read the time format if it had no spaces in it e.g. 2015-06-09T07:49:16.610635000-0700 rather than 2015-06-09 07:49:16.610635000 -0700. It's not obvious in the examples in the post, which all line up very nicely, but it would be more obvious in a collection of times. Also, doesn't 610635000 represent nanos? The post refers to millis.

Lastly, and I realize this is a bit of work (though it could probably be automated), I'd turn the names of all the contributors to links to their github profiles.

[myronmarston]

Thanks for the feedback!

I think it would help to mention (even if it might seem obvious) the fact that you can set meta[:aggregate_failures] = true globally and then override it for individual examples to false. That section implies that, but is not specific about it.

Good point. The snippet I posted actually didn't allow that to work, so I tweaked it a little and mentioned you can do that.

This is almost assuredly too late, but I think it would be easier to read the time format if it had no spaces in it e.g. 2015-06-09T07:49:16.610635000-0700 rather than2015-06-09 07:49:16.610635000 -0700. It's not obvious in the examples in the post, which all line up very nicely, but it would be more obvious in a collection of times.

Too late to get in 3.3, but not too late overall. Can be a future improvement. Conversation moved to rspec/rspec-support#213.

Also, doesn't 610635000 represent nanos? The post refers to millis.

Probably. I get my subsecond units confused past milliseconds, to be honest. The point I was trying to make was that the times differ at a subsecond level, not to try to name a particular unit. I updated the text -- does it read better to you now?

Lastly, and I realize this is a bit of work (though it could probably be automated), I'd turn the names of all the contributors to links to their github profiles.

rspec/rspec-dev#123

[dchelimsky]

Probably. I get my subsecond units confused past milliseconds, to be honest.

millis: 3 digits
mics: 6 digits
nanos: 9 digits

[dchelimsky]

does it read better to you now?
Yep, thanks!

[cupakromer]

rspec-rails stuff looks good to me 👍