Update Castle.Core netstd dependency to match project.json

[blairconrad]

Without this, consumers of our package find

 System.MissingMethodException : Method not found: 'System.Collections.Generic.IList`1<Castle.DynamicProxy.CustomAttributeInfo> Castle.DynamicProxy.ProxyGenerationOptions.get_AdditionalAttributes()'.

[blairconrad]

workaround: reference 4.0.0-beta002 in the test project's project.json.

[thomaslevesque]

Oops! Forgot to update that.

[thomaslevesque]

Thanks for the fix @blairconrad!

[blairconrad]

😉

Thanks for the merge!

Now, as a bug that was introduced in 3.0.0-alpha001, should we put in the release notes for 3.0.0-alpha002?
(But not in 3.0.0, when we release that?)

[adamralph]

Now, as a bug that was introduced in 3.0.0-alpha001, should we put in the release notes for 3.0.0-alpha002?
(But not in 3.0.0, when we release that?)

I think so. Perhaps it would be easier to have real milestones for each alpha, beta, etc.? Rather than the 3.0.0-pre "catch-all" milestone?

[blairconrad]

Perhaps it would be easier to have real milestones for each alpha, beta, etc.? Rather than the 3.0.0-pre "catch-all" milestone?

This meshes nicely with my belief that we should "treat all releases the same". I'd go so far as to make a milestone, release issue, and release for every release.

Along with that, I'd commit the full version number, and ditch the version_suffix environment variable. But perhaps that's a story for another day.

In the short term, I'll add this to the release notes.

[adamralph]

One reason I like version_suffix is that it allows us to build RC and RTM
from the same commit.

[blairconrad]

One reason I like version_suffix is that it allows us to build RC and RTM.

Yeah. I know. I have contrary views. But that's okay. I don't mind. 😼