Skip to content

Release React v0.8 #639

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zpao opened this issue Dec 6, 2013 · 5 comments
Closed

Release React v0.8 #639

zpao opened this issue Dec 6, 2013 · 5 comments
Assignees

Comments

@zpao
Copy link
Member

zpao commented Dec 6, 2013

But we're at 0.5 right now…

We've been working with @jeffbski and he has graciously allowed us to take over the react package on npm. However, that's currently versioned at 0.7.x, so in order for this to work in a reasonable way, we're going to jump to 0.8. This allows users of the current react package to continue working. So long as they have reasonable specs in their package.json (~0.7.1) then they won't break. In our package we will issue a warning pointing at the new package if you use react as a function (which is the typical use of @jeffbski's package). We'll leave 0.7.x on npm as well.

Where to cut?

Typically we've cut from the latest stable commit in master. However we don't feel like master is stable enough right now to cut a release we will support, so we're going to go farther back. We have a couple options:

  • Some have suggested we just take 0.5 and rebrand it, then pull in a couple other commits for small bugfixes. This is the easy way.
  • Pick a commit more recent than 0.5 as the base and cherry-pick some other changes in. There are a lot of good fixes in there that would make this a bit painful but probably has the best result for consumers.

What about react-tools?

Nothing will change here. Except it will probably use the react package directly instead.

How does this affect future releases?

Right now it doesn't. But while we're screwing around with version numbers this gives us a chance to try something new (for us). Currently we follow the typical pattern of "every release is stable", but the result of that is that we sit on things for a while before they're usable. Master is generally usable but there are no checkpoints, just latest.

While it would be great to move towards a time-based release schedule, I'm not sure it makes sense for us that this point. We're still changing APIs pretty frequently and don't have a good pattern for backing out features.

I'd like to move towards the pattern that Node.js uses (and the Linux kernel used to use) where even minor releases are stable and odd are for development. We would publish these releases just like we would our stable ones but make sure they aren't installed with a plain npm install react (e.g. if we do npm publish --tag 0.9.0 that wouldn't be installed unless you do npm install [email protected]). We could publish the unstable releases on a regular schedule (once per week) and then publish stable release when they're ready.

Or we can take advantage of the same tagging feature in npm and just use semver pre-release versioning (e.g. 0.9.0-alpha.2013-12-05). Regardless, it's not immediately important but I'm thinking about it.


Let's collect thoughts here and then get a list of commits we need to cherry-pick once we figure out the exact plan.

@ghost ghost assigned zpao Dec 6, 2013
@sophiebits
Copy link
Collaborator

If I remember right, part of the motivation for this would be that external users could do require('React') matching FB's internal style exactly. However, npm package names are required to be lowercase and require is case-sensitive on Linux so that means people will need to do require('react') instead…

@zpao
Copy link
Member Author

zpao commented Dec 6, 2013

Yea, we've accepted that lowercase is the only real option here. npm actually even prohibits capitalized package names. That might force us to eventually change internally, but it at least makes it a relatively painless transition.

@zpao
Copy link
Member Author

zpao commented Dec 6, 2013

Ok, so part of the decision was made. We're going to base 0.8 on 0.5-stable. We're not going to take any API changes, but we'll take bugfixes from master. This makes things way easier and also let's people switch to 0.8 without worrying about breaking changes. This also means we need to do what we did for #439 and list out commits that will need to be cherry-picked/backported and excluded.

Building and testing is going to lack the coverage we have on master, but that's fine. With any luck we'll have vNext cut soon (it's unlikely anything will happen there before 2014).

Please add commits/PRs that you think should be in 0.8 and I'll update the description of this issue with the updated state.

@zpao
Copy link
Member Author

zpao commented Dec 7, 2013

@spicyj suggested a spreadsheet... here's all the changes in master that should be considered: https://docs.google.com/spreadsheet/ccc?key=0AmorHpAY7s4edEZWQmRXVnU3Y3NZUjlOWTY0MDNVS2c&usp=sharing

Generated with this and imported as a CSV:

git log --pretty=format:'%h | %s | https://github.com/facebook/react/commit/%h' --reverse --abbrev-commit --no-merges 48281a1...master src

We'll figure out changes outside of src/ outside of the spreadsheet

@zpao
Copy link
Member Author

zpao commented Dec 20, 2013

Thanks for all the help! We're all done here :)

@zpao zpao closed this as completed Dec 20, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants