-
Notifications
You must be signed in to change notification settings - Fork 200
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
May blog update #109
May blog update #109
Conversation
@chrisglein - is it cool to add the release processes information in this blog post? I know some stuff isn't 100% final yet... |
I'd keep it detail light given that yes, it's not 100% final. Some of that is aspirational now, not practical. For example the "white glove" experience between official releases is more like "we intend to guide apps through the upgrade process, but we haven't fleshed that out yet". |
|
||
| <div style="width:120px">Title</div> | <div style="width:300px">Expectations</div> | <div style="width:300px">Promises</div> | | ||
|:--|:-----|:-----| | ||
| **Canary** | Released per day (ish) or per commit, depending on what's least expensive and necessary. All CI's pass.| The release builds, maybe it only builds on one flavor, but CI's work and pass.<br>No white glove experience, none to minimal communication about the release with full knowledge to consumers that things could be in a bad state/broken in places.| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't quite match the current naming that happened organically. "Official Release" has corresponded to the npm dist-tag of latest
out of tooling expectation. Preview is the same. Nightly(ish) builds are currently tagged as master
, but canary
came up as a possible name as well (we can change things if we want to).
Canary/Master aren't guaranteed to be tied to a released version of upstream React Native, which ends up being big for consumers since they can't necessarily use a bunch of the things they're used to.
CI should be passing for all builds, regardless of channel.
Preview builds aligning to FB stable builds when we're caught up means we might not have done much manual validation of the initial preview build, or it may have some issues.
Planning to send out a doc soon with details of what the process and bar looks like internally. I think that might be useful to form what guarantees we make to the public. I would agree with Chris in biasing towards not over-promising on any point until things have settled a bit, since a lot of details are subject to change based on our experiences. |
Copying and pasting from a draft of the current doc to be sent to engineers: Release DistributionsThis branching and stabilization has lead to three release distributions with corresponding tags:
|
changed the release process table definitions based on @NickGerleman 's feedback.
@NickGerleman I added your comment snippet above to the releases table at the end of this blog. Hope that's okay/what you intended. Let me know if it looks good to you. |
Removed the releases section, updated and added to the initial announcements blurb at the top, rearranged sections. Reworded module announcements based on feedback and added the following module callouts: NetInfo, AsyncStorage, Pick, and DateTimePicker. More links were added, to other RN announcements, community modules and within the samples repo itself.
links added to new macos
hardcoded the macos getting started link.
First initial push of the may blog updates for RNWM.