Skip to content
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

Merged
merged 6 commits into from
May 19, 2020
Merged

May blog update #109

merged 6 commits into from
May 19, 2020

Conversation

kikisaints
Copy link
Contributor

First initial push of the may blog updates for RNWM.

@kikisaints
Copy link
Contributor Author

@chrisglein - is it cool to add the release processes information in this blog post? I know some stuff isn't 100% final yet...

@kikisaints kikisaints marked this pull request as draft May 15, 2020 21:57
@chrisglein
Copy link
Member

@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".
Adding @NickGerleman to take a look and coment as well.


| <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.|
Copy link
Contributor

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.

@NickGerleman
Copy link
Contributor

@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".
Adding @NickGerleman to take a look and coment as well.

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.

@NickGerleman
Copy link
Contributor

Copying and pasting from a draft of the current doc to be sent to engineers:

Release Distributions

This branching and stabilization has lead to three release distributions with corresponding tags:

  1. Master (@master)
  2. Preview (@preview)
  3. Latest (@latest)

master builds are built directly from our master branch. These builds provide no guarantees around upstream React version, breaking changes, or overall stability. These builds should be used for development or to test bleeding edge functionality, but should not be relied upon for production use. Master builds are versioned as 0.0.0-master.x.

preview builds are the first released by stable branches. These builds aim to become increasingly polished over time, and have less breaking changes than in master. react-native-windows-init will consider preview builds but warn users before installing them. Preview builds are versioned as 0.x.0-preview.y where x matches the minor release of React Native.

latest builds are kept free of breaking or high-risk changes. These are considered to be stable but will still receive bug fixes for customer-blocking issues. Latest builds are versioned as 0.x.y where x matches the minor release of React Native.

changed the release process table definitions based on @NickGerleman 's feedback.
@kikisaints
Copy link
Contributor Author

@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.

website/blog/2020-05-18-rn4mupdadates.md Outdated Show resolved Hide resolved
website/blog/2020-05-18-rn4mupdadates.md Outdated Show resolved Hide resolved
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
@kikisaints kikisaints marked this pull request as ready for review May 19, 2020 17:17
hardcoded the macos getting started link.
@harinikmsft harinikmsft merged commit 528ae3a into master May 19, 2020
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

Successfully merging this pull request may close these issues.

4 participants