-
Notifications
You must be signed in to change notification settings - Fork 48.5k
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
Comments
If I remember right, part of the motivation for this would be that external users could do |
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. |
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. |
@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:
We'll figure out changes outside of |
Thanks for all the help! We're all done here :) |
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 currentreact
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:
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 donpm publish --tag 0.9.0
that wouldn't be installed unless you donpm 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.
The text was updated successfully, but these errors were encountered: