Ship 0.11.2

[zpao]

I think we want to get React.createElement out there. We can take some ridealongs for new elements or properties or any non-breaking bug fixes. List them if you have them.

• Add support for <dialog> tag. #2033
• add picture element and related attributes #1848
• Add createElement for 0.11 #2177
• Add --strip-types flag to bin/jsx #2153 (needs jstransform & esprima bumps - bcc291b - slightly risky but needed for some tooling)

[sophiebits]

Can we have .key and .ref on the descriptor (and still in props) in this release to allow people to switch to using .key when appropriate for future-looking code? @sebmarkbage

[sophiebits]

Can we have createFactory too? Trying to preemptively start fixing up KA code (before upgrading React) and it's easier if I can do it all now instead of having to do it synchronously with the upgrade.

[kossnocorp]

Please increase minor version if you adding something to API. See issue in immutable-js.

[sebmarkbage]

I thought we already has createFactory?

On Sep 4, 2014, at 12:51 AM, Ben Alpert notifications@github.com wrote:

Can we have createFactory too? Trying to preemptively start fixing up KA code (before upgrading React) and it's easier if I can do it all now instead of having to do it synchronously with the upgrade.

—
Reply to this email directly or view it on GitHub.

[sophiebits]

Me too but it doesn't seem to be in 0.11.1.

[sebmarkbage]

We didn't need an intermediate release for key/ref because it is greppable. You can probably find your uses using just grep. We did. So I figured it would be ok to play hardball on that one. We've always introduced some breaking change with releases without deprecating them first.

Do you foresee trouble upgrading at KA?

On Sep 4, 2014, at 12:47 AM, Ben Alpert notifications@github.com wrote:

Can we have .key and .ref on the descriptor (and still in props) in this release to allow people to switch to using .key when appropriate for future-looking code? @sebmarkbage

—
Reply to this email directly or view it on GitHub.

[sophiebits]

No, shouldn't be a big deal.

[syranide]

Ping @sebmarkbage #1988 (no rush from my side, just a reminder)

[zpao]

@kossnocorp We won't be bumping the minor version even if we add a couple small things. Right now PATCH really is our MINOR.

1. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
   — semver

I totally understand your argument though and I'm not trying to be rude, just letting you know we're taking advantage of the "fuck the other rules pre-1.0" rule while we can. API additions are for transitional purposes while updating your own codebase. We won't break or change existing APIs though. We're trying to be as interop and semver as possible while sticking to a slower-moving schedule (it's not practical for us to bump versions at the rate of say browserify). When we get to 1.0, the plan is to be much more strict about the real rules.

[mtscout6]

What is the issue or commit related to React.createElement so I can start getting familiar with the upcoming change?

[jeffchan]

@mtscout6 See https://gist.github.com/sebmarkbage/ae327f2eda03bf165261

[zpao]

@mtscout6 it's currently in 0.11.x as createDescriptor, which just calls the function it's passed. It will be more involved/versatile in 0.12

[zpao]

@syranide you mentioned #1988 here but I don't think we should take it in the branch. Did you want it there or just reminding @sebmarkbage in as many places as possible?

[syranide]

@zpao Just a reminder, push ahead :)

[mtscout6]

How does the JSX React.createElement change work with the core proposal on stateless functions?

[zpao]

http://facebook.github.io/react/blog/2014/09/16/react-v0.11.2.html

cdnjs and jsdelivr should be set up to pick up the changes from npm/bower automatically. I think that's all folks.