Final Decision: Release channels and cadences #637
Replies: 11 comments 35 replies
-
|
I don't think we need the complexity of two pre-release channels. The scenarios/motivations here make sense, but I'd like to start out simpler and see what happens. (The single channel approach has been working well for WinUI2.) I know sometimes we need to make long-term advance commitments for certain features, and predict 6 months ahead of time that something is going to be release ready. But our general flow should be that we work on features and when we feel they’re ready we push them out on the next release. We can be flexible. |
Beta Was this translation helpful? Give feedback.
-
|
Which channels are you referring to exactly? Just want to make sure we're on the same page. |
Beta Was this translation helpful? Give feedback.
-
|
Mike is referring to Channel 2 ("Preview", only contains features that are slated to ship in that upcoming release) and Channel 3 ("Experimental", includes long-run experimental features that are slated to release in a future release). |
Beta Was this translation helpful? Give feedback.
-
|
@MikeHillberg question for you, does WinUI2 do any "release candidate" releases just before a final release? For example, say 1.3 is coming up, if we were combining experimental and near-final features in one channel, I feel like we'd need to have a "release candidate" release a month before the final release, which only contains the supported final features, so we can verify the behavior of the packages without any experimental features before we do the final release. |
Beta Was this translation helpful? Give feedback.
-
|
No, WinUI2 doesn't do an RC release, just Preview/Experimental and Release. And there's a lot of channels going on here, which is why I was unsure. But thinking on it more I think the RC is a good idea. |
Beta Was this translation helpful? Give feedback.
-
What are these priorities for? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, a definition of the meaning and application of the priorites would be useful to fully understand the intent here. |
Beta Was this translation helpful? Give feedback.
-
|
The priorities are to help capture how important we think the existence of each channel is (and importance can include things like what customers need to validate/develop/test their apps, what we need to validate/test releases, etc). P0 == Critical (if deemed P0, we'd almost certainly have these channels) |
Beta Was this translation helpful? Give feedback.
-
|
In that case, I'd put the experimental channel as P2 |
Beta Was this translation helpful? Give feedback.
-
|
Even if there are separate channels for "preview" and "experimental" features there needs to be solid definitions of what these terms mean for features/tools/controls/functionality. Putting "experimental" functionality behind a feature flag would avoid anyone accidentally using it if included in the "preview" release. From the description it sounds as though the preview channel is also being treated as a test for what will become the stable/GA release. If this is the case, how might the preview release change over a 6 month period prior to a GA release? I'm also concerned that GA will only get 2 releases a year. I thought the aim was three. I'm also unclear about your "What does this look like?" table.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks Matt, excellent feedback 😊 Agreed, definitions are super important. I think your definitions are spot on, I'll look at incorporationg some of that. I did have a bit of a definition of experimental features in the post: Experimental features are features that are "long-run features" and will take multiple releases till they are part of a supported release. For example, in the 1.0 timeframe we might start working on feature XYZ, and there might be something to try in the 1.1 timeframe (considered experimental at that time), but it won't be released till the 1.2 release.
Yes, that is how the Preview channel would be treated in the proposal I wrote up. Curious to know how you think that would work if experimental features were included in the Preview channel... if they were behind some sort of feature flag, you think that'd be okay? What would that feature flag look like to you as a developer?
Good questions. I'm not sure we communicated that we were aiming for three releases a year. But this is the perfect time to get feedback on this, so I'm looking forward to what more people have to say :) And for projects that are part of Project Reunion but want to release more often than twice a year, they wouldn't be able to (but that could be a driving factor to make us consider releasing more frequently... so far, I don't think we have those requirements). And your table you created is the same as the one in the proposal (if you remove the Canary releases, it'll look essentially the same as what you have... curious what you found different/confusing, let me know!) |
Beta Was this translation helpful? Give feedback.
-
|
The definitions of "preview" and "experimental" also need to include what people using the libraries/tools can expect. Subject to it being clearly defined 😉 I think of experimental features as being consumed on a "on your head be it" basis. They come with no guarantee or support. I appreciate that policy from elsewhere in the business may mean they are not available in stable builds. Regarding the table, on having now re-read it several times I see they do represent the same thing. |
Beta Was this translation helpful? Give feedback.
-
|
@BenJKuhn what Xamarin Forms does is an interesting approach. Experimental features are actually still part of their GA releases. But devs have to call an API to say Thoughts on that? |
Beta Was this translation helpful? Give feedback.
-
|
My preference would be experimental features are in stable builds. |
Beta Was this translation helpful? Give feedback.
-
|
I agree - stay away from feature flagging non-GA features in "supported" channels. Using feature flags is saying "here's some production ready code, but don't use that bit over there because it's not-supported" and just doesn't make sense. By all means use feature flagging in prerelease/experimental channels, particularly if some feature causes some instability or is underdevelopment |
Beta Was this translation helpful? Give feedback.
-
|
Sounds okay to me. I'll echo back my takeaway.
Outstanding items that are probably out of scope:
|
Beta Was this translation helpful? Give feedback.
-
|
It would be great to see further consideration be given to a LTS channel. As an enterprise developer I should be able to set my environment up to only use LTS bits (as a .NET developer this would be the latest LTS version of .NET coupled with the LTS reunion bits). |
Beta Was this translation helpful? Give feedback.
-
|
A couple of comments:
|
Beta Was this translation helpful? Give feedback.
-
|
Terminology is really difficult here; we're in a high synonym environment. Experimental has a concrete manifestation in this ecosystem in the form of the [Experimental] attribute. That's what we put on our in-development APIs today, and we have compiler support today such that if you call one of those APIs you get a warning that you're using an "experimental" API. It's developer-facing, so we shouldn't use that word in any way that conflicts. Prerelease is the word that VS and nuget.org use for "not a release". We looked around, and despite that precedence, most packages seem to use "preview" today, so we used that for Reunion. (WinUI2 uses "prerelease".) We shouldn't think of experimental features as necessarily far-out; they're just APIs we're not confident about yet. We could get confident about them tomorrow and ship them soon. To feel confident about an API we want to do a full spec review on it for sure, but we also really want to co-develop with a partner that's going to use it. At least some real sample app code and not just unit tests. We may get comfortable with it in the next release or next next, but we want to make it available so we can have the opportunity to find out. But I don't think we should get into the business of trying to predict the timeframe of every API; it just won't be reliable enough to be a beneficial indicator. I like having what I believe is option 2:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks Mike! Great feedback! |
Beta Was this translation helpful? Give feedback.
-
|
Btw, another indicator is when a new API is in a not-yet-released channel, but also not marked [Experimental]. That indicates that the API's been spect and reviewed and tried out, and generally that the team feels confident that it's ready to go out in the next release. |
Beta Was this translation helpful? Give feedback.
-
|
I really like talking about how the code itself reflects what's in each version. Someone else asked how the branching strategy would correlate to the channels, and I think that helps explain it.
Does that map up with how you're thinking the code/tags/branches correspond to the two channels? Quite sure it does but I like to clearly state and verify to make sure there's no gaps in my knowledge :) |
Beta Was this translation helpful? Give feedback.
-
|
I generally don’t like the idea of multiple-release experimental features. Ie I’d like to see nightly-builds with “next version” features on an azure feeds, semi-regular preview builds on NuGet, but other than that, if a feature is so far from being ready that it is several releases out, it shouldn’t be in the main branch yet, and you should focus your resources on completing next-release features, and keep long-running work in a branch or behind a compiler-flag. Basically I’d ditch the SC3 scenario entirely. If people really want to work with far-out-in-the-future stuff, they can pull and build the branch (make that easy btw, or have CI builds with artifacts for those branches). IMHO such a feature would be too early for others to start testing and provide usable feedback until it gets a little more solid. One thing that confused me in the first table: Things become stable before a GA release:
From my understanding these are just project templates. They aren’t a requirement to ship are they? Use latest vsix if you want the templates, then upgrade the nuget package manually to a preview-build. Regarding release cadence of 6mo: I think that is too slow. Smaller more frequent releases please (even if they are just patch releases). If you really do want to do experimental releases, completely rename the packages (fx. Microsoft.ProjectReunion.WinUI.Experimental). That avoids the issue with using 0.x versioning. I’d still keep them out of nuget.org though. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Morten! Great feedback! I'll double check with the team to see if we have had any concrete scenarios where we've really had to have experimental features across multiple releases where it was common enough that just having separate branches+builds with those features wouldn't be good enough. Although react does include experimental features in their main branch, and has a stable "latest" release that doesn't include the experimental features... so it's not only us. To clarify that table, "Stable" in that table means the API no longer has the "Experimental" flag. A feature hopefully goes "Stable" before the GA so that it's included in at least one preview release before GA'ing. |
Beta Was this translation helpful? Give feedback.
-
|
Oh and yes the VSIX isn't required, it's only for project templates and item templates (which sometimes might change... probably will change much more in the early days compared to in a year or two). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for explaining the table. It's still a little odd though, if it's in a preview release I'd consider it preview until the GA release. |
Beta Was this translation helpful? Give feedback.
-
|
These proposals that strip functionality and metadata from the shipping G/A builds will cause regressions from how WinUI and IXP work today. We are following up with @andrewleader and @BenJKuhn and @jonwis and @DrusTheAxe on requirements. |
Beta Was this translation helpful? Give feedback.
-
|
Please provide feedback on the updated proposal!! Here's a condensed version of where I think we're converging to... (you can see the full proposal with all options updated in the main posting). Note that we aren't discussing naming yet, so just using generic terms like "Next release" and "Long-lead". We're proposing having three channels as seen below (currently we have two channels, "Stable" and "Long-lead", the "Next release" channel is the new addition). We aren't discussing cadences at this time yet either, that can be a separate topic.
What this looks like with features ABC and XYZ from earlier...
Distribution source of long-lead: Separate Azure feedThe long-lead channel would be distributed on a separate Azure feed rather than NuGet.org, which means your experience accessing the long-lead channel would look something like the following...
Share your feedback!Please let us know what you think! Let us know what you agree with and let us know what you disagree with and why! |
Beta Was this translation helpful? Give feedback.
-
|
We've made a final decision on proposed changes 1 & 2! We agreed to have the three channels seen below (names are just placeholders), and that the "long-lead" channel will be versioned X.X (like 1.3 and 1.4).
What this looks like with features ABC and XYZ from earlier...
We still haven't made a final decision on the remaining topics, like where the long-lead channel should be hosted or naming, please share feedback! Proposed distribution source of long-lead: Separate Azure feedThe long-lead channel would be distributed on a separate Azure feed rather than NuGet.org, which means your experience accessing the long-lead channel would look something like the following...
Share your feedback!Please let us know what you think! Let us know what you agree with and let us know what you disagree with and why! |
Beta Was this translation helpful? Give feedback.
-
|
@andrewleader Looks good. When you sit down to decide final naming, do consider that pre-release identifiers are ordered lexically to determine precedence. This will constrain your creativity and will need to be carefully planned out. (No pressure!) For example, |
Beta Was this translation helpful? Give feedback.
-
|
@riverar That would make |
Beta Was this translation helpful? Give feedback.
-
|
@dotMorten I presume the actions not shown above are:
|
Beta Was this translation helpful? Give feedback.
-
|
"Names are placeholders" = "stable, "next", "next release", "long" and "long-lead" are just working names. The actual names almost certainly won't be the same (OK, maybe stable, but as the 'release'/final it gets no tag in SemVer). Edge+Chrome call their channels Dev<Canary<Beta. Other terms used in the industry include Release, Prerelease, ReleaseCandidate (RC), Preview, Experimental, Alpha, Nightly and more. Trying to use our previous terminology (release+preview) while trying to discuss the future only distracted people. The easiest way to get folks to focus on the options and intent was to use intentionally blandly generic terms for now. Thank you for raising the lexical-tag-sort issue. A good reminder of one of the less well known facets of SemVer |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! And to close on "the purpose of |
Beta Was this translation helpful? Give feedback.
-
|
Next set of pending decisions!! Please provide feedback on these if you wish! Proposed change #3 - Should long-lead be on NuGet.org or separate feed?Should the long-lead be on NuGet, or should we have it on a separate Azure feed? What do other NuGet packages do?
If we host long-lead NuGet packages on Azure feeds (Proposed choice)
If we host long-lead NuGet packages on NuGet.org (Alternative choice)
Proposed change #4: Bars for moving across a release channelWhat will be the bar for moving a feature from long-lead to next release? Or from being added to long-lead in the first place? Bar for long-lead:
Bar for next release:
Bar for stable release:
Proposed change #5: NamesCandidates
Requirements
ProposalsWe'll consider proposals of the whole set of names, since in some cases, the names are relative to each other (and if we have the alphabetical requirement, that changes things too). Proposal 1 - Stable, Preview, and Experimental
Proposal 2 - Stable, RC, and ExperimentalWhere RC == Release candidate
Proposal 3 - Latest, Next, Experimental
Proposal 4 - Stable, Beta, Experimental
Proposal 5 - Stable, Beta, Alpha
Proposal 6 - Stable, Beta, Dev (aligns with Edge channels)
Any other options you'd like to see?If there's any other option you think is worth considering, let us know! |
Beta Was this translation helpful? Give feedback.
-
|
Separate topic.
I think there's a misunderstanding of how NuGet feeds work in the proposals above. There is no "make sure you're on the correct NuGet feed" that I'm aware of. There's instead a configured list of sources that are all polled for packages, then nuget performs the hard work of creating the dependency graph. |
Beta Was this translation helpful? Give feedback.
-
|
@riverar depends on how you use the NuGet Package Manager. You can select "All" sources, or you can select specific sources.
If you select "All", then it'll behave as you described. Although regardless of these details, I do personally agree with what you're both saying :) |
Beta Was this translation helpful? Give feedback.
-
|
My votes: Proposed change 3 - Should long-lead be on NuGet.org or separate feed?Separate feed, mainly to avoid accidental consumption. Proposed change 4: Bars for moving across a release channel
Proposed change 5: NamesAgree with option 1: Stable, Preview, and Experimental, for the originally listed reasons. Regarding other options, you did a great job summarizing why they are less than ideal; I have nothing to add. |
Beta Was this translation helpful? Give feedback.
-
Proposal 3 - Should long-lead be on NuGet.org or separate feed?
Proposal 4: Bars for moving across a release channel
Proposal 5: Names
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks @amartens181! I added Alpha -> Beta -> Stable to the list of proposals, good one that I didn't think of! About Proposal 3, in either case, both the "long-lead" and "next" versions will be hidden behind the "include prerelease" option on NuGet, so there's really no risk of accidently installing a prerelease package without realizing it (you explicitly have to check a checkbox in Visual Studio to include the prerelease packages). The only accidental risk is if we have both long-lead and next on NuGet (hidden underneath prerelease), and you might accidentally install the long-lead without realizing the implications (less stable APIs, contains features that are potentially a long-ways away, etc). Thanks for your feedback! |
Beta Was this translation helpful? Give feedback.
-
Like many other developer SDKs, we need to have multiple release "channels", where we have "stable/GA" releases, "preview/beta" releases, etc.
✅ Approved final release channels
Definitions:
[Experimental]attribute to indicate to developers that it's experimental.(+servicing)
❇️ Preview
❇️ Preview
🔁 Experimental
Some further explanations...
mainbranch, including APIs tagged[Experimental].The NuGet feed in NuGet Package Manager will look something like this (previews will always show up as "newer" than experimental due to reverser alphabetical sorting, which helps ensure developers have to make an explicit choice to use the experimental channel and don't accidently upgrade to experimental versions)...
1.4.0(ABC)1.4.0(ABC)1.3.11.4-preview2(ABC)1.3.01.4-preview1(ABC)1.2.11.4-experimental3(ABC+XYZ)1.2.01.4-experimental2(ABC+XYZ)1.1.11.4-experimental1(ABC+XYZ)1.1.01.3.1Bars for getting a feature into each release...
Some additional notes...
ARCHIVED INFO - BELOW PRESERVED FOR HISTORICAL PURPOSES
Call to action
Please read through the below sections and then share your feedback on the proposed requirements! We're locking down these requirements and channels with the help of the community, we haven't agreed on anything yet, so now is the perfect time to make your feedback heard! We'll be sharing our opinions alongside yours 😊
Scenarios (proposed - anything missing?)
Overall release scenarios...
FYI, the above names are placeholders and not final names.
1.3 GA1.4 GA1.5 GACustomer scenarios...
Reunion team scenarios...
Repository scenarios
This is TBD and will be finalized after we make a decision on channels, but probably will look something like this...
Restrictions
We ship packages through NuGet, which only allows for one "channel". They have a concept of "prerelease" (which is indicated by anything using
-after the version), but everything is sorted by version number (and then the-betaor-nextare sorted reverse alphabetical)We also ship tooling via VSIX extensions, and the VSIX marketplace doesn't have a concept of multiple channels either. Additionally, it doesn't have the concept of multiple versions. Only the latest version is ever available. However, scenarios where we need a VSIX change should be rare, since the VSIX only carries project and item templates.
Feedback from customers and team
0.0-xxxfeels odd, I'd have the experimental versions be one version ahead, so if1.1is the next GA release, experimental would be1.2.0.0for experimental...0.0-xxxfeels odd, I'd have the experimental versions be one version ahead, so if1.1is the next GA release, experimental would be1.2What we're currently doing...
We currently have "previews" of releases which include long-lead features. And then for the final release, we remove those long-lead features from the release. So, when you update from 0.8-preview2 to 0.8, you lose features.
(+servicing)
❇️ Next release
🔁 Long-lead
What this looks like with features ABC and XYZ from earlier...
1.3.0 GA1.3.11.4 GAABC (1.4)
1.4.1ABC (1.4)1.5 GAABC (1.4)
XYZ (1.5)
1.4-preview11.4-preview2ABC (1.4)
XYZ (1.5)
1.4-preview3ABC (1.4)
XYZ (1.5)
1.5-preview1ABC (1.4)
XYZ (1.5)
1.5-preview2ABC (1.4)
XYZ (1.5)
1.5-preview3ABC (1.4)
XYZ (1.5)
1.6-preview1ABC (1.4)
XYZ (1.5)
Why this isn't ideal...
Accepted change #1 - Add a third channel that only has features that'll be in the next release (release candidates)
"Preview" temporarily renamed to "Next release" so that naming isn't discussed yet
Essentially, the "Next release" channel is our "release candidate", reflective of what will be in the next release. And then we add a third channel for our long-lead features (what we currently call "Preview")
(+servicing)
❇️ Next release
❇️ Next release
🔁 Long-lead
What this looks like with features ABC and XYZ from earlier...
1.3.0 GA1.3.11.4 GAABC (1.4)
1.4.1ABC (1.4)1.5 GAABC (1.4)
XYZ (1.5)
1.4-next11.4-next2ABC (1.4)
1.5-next1ABC (1.4)
1.5-next2ABC (1.4)
XYZ (1.5)
TBD-long2101TBD-long2102ABC (1.4)
XYZ (1.5)
TBD-long2103ABC (1.4)
XYZ (1.5)
TBD-long2104ABC (1.4)
XYZ (1.5)
TBD-long2105ABC (1.4)
XYZ (1.5)
TBD-long2106ABC (1.4)
XYZ (1.5)
TBD-long2107ABC (1.4)
XYZ (1.5)
Concerns
Accepted change #2 - Version numbers for "Long-lead" channel - X.X
How should the long-lead channel be versioned? A single release in the long-lead channel isn't really reflective of a release number that corresponds with the Stable releases (for example, in the 1.4 timeframe, the long-lead channel might have features that will be part of the 1.6 or 1.7 release).
If we go with X.X (Accepted)
1.3.0 GA1.3.11.4 GAABC (1.4)
1.4.1ABC (1.4)1.5 GAABC (1.4)
XYZ (1.5)
1.4-next11.4-next2ABC (1.4)
1.5-next1ABC (1.4)
1.5-next2ABC (1.4)
XYZ (1.5)
1.3-long31.4-long1ABC (1.4)
1.4-long2ABC (1.4)
XYZ (1.5)
1.4-long3ABC (1.4)
XYZ (1.5)
1.5-long1ABC (1.4)
XYZ (1.5)
1.5-long2ABC (1.4)
XYZ (1.5)
1.5-long3ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April... (we need to make sure we never publish a higher number experimental without a preview of the same number existing, so devs don't accidently update to experimental).
1.4.0(ABC)1.4.0(ABC)1.3.11.4-next2(ABC)1.3.01.4-next1(ABC)1.2.11.4-long3(ABC+XYZ)1.2.01.4-long2(ABC+XYZ)1.1.11.4-long1(ABC+XYZ)1.1.01.3.1(ABC+XYZ)Concerns
What others do...
0.0-longerimental48f2a807.0.0-build.1096+cd6d726dd9.Proposed change #3 - Should long-lead be on NuGet.org or separate feed?
Should the long-lead be on NuGet, or should we have it on a separate Azure feed?
What do other NuGet packages do?
If we host long-lead NuGet packages on Azure feeds (Proposed choice)
-longmain version number: No restrictions ✅1.4.0(ABC)1.4.0(ABC)1.5-long1(ABC+XYZ)1.3.11.4-next2(ABC)1.4-long3(ABC+XYZ)1.3.01.4-next1(ABC)1.4-long2(ABC+XYZ)1.2.11.3.11.4-long1If we host long-lead NuGet packages on NuGet.org (Alternative choice)
-longmain version number: Limited-next's first (otherwise-longwill be suggested first for users if we have long at 1.5 when next/GA is only at 1.4).1.4.0(ABC)1.4.0(ABC)1.3.11.4-next2(ABC)1.3.01.4-next1(ABC)1.2.11.4-long3(ABC+XYZ)1.2.01.4-long2(ABC+XYZ)1.1.11.4-long1(ABC+XYZ)1.1.01.3.1(ABC+XYZ)Proposed change #4: Bars for moving across a release channel
What will be the bar for moving a feature from long-lead to next release? Or from being added to long-lead in the first place?
Bar for long-lead:
Bar for next release:
Bar for stable release:
Proposed change #5: Names
Candidates
Requirements
Proposals
We'll consider proposals of the whole set of names, since in some cases, the names are relative to each other (and if we have the alphabetical requirement, that changes things too).
Proposal 1 - Stable, Preview, and Experimental
Proposal 2 - Stable, RC, and Experimental
Where RC == Release candidate
Proposal 3 - Latest, Next, Experimental
Proposal 4 - Stable, Beta, Experimental
Proposal 5 - Stable, Beta, Alpha
Proposal 6 - Stable, Beta, Dev (aligns with Edge channels)
Any other options you'd like to see?
If there's any other option you think is worth considering, let us know!
OLD OPTIONS (No need to continue reading further, preserved for historical purposes)...
If we go with 0.0 (Rejected choice)
1.3.0 GA1.3.11.4 GAABC (1.4)
1.4.1ABC (1.4)1.5 GAABC (1.4)
XYZ (1.5)
1.4-next11.4-next2ABC (1.4)
1.5-next1ABC (1.4)
1.5-next2ABC (1.4)
XYZ (1.5)
0.0-long21010.0-long2102ABC (1.4)
0.0-long2103ABC (1.4)
XYZ (1.5)
0.0-long2104ABC (1.4)
XYZ (1.5)
0.0-long2105ABC (1.4)
XYZ (1.5)
0.0-long2106ABC (1.4)
XYZ (1.5)
0.0-long2107ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April...
1.4.0(ABC)1.4.0(ABC)1.3.11.4-next2(ABC)1.3.01.4-next1(ABC)1.2.11.3.11.2.01.3-next20.0-long2104(ABC+XYZ)0.0-long2013(ABC+XYZ)If it's on NuGet and we use 0.0 (Alternative choice)
Developers would have to scroll down a ways to get to the 0's (slightly tough to find 😒 and even tougher since we had 0.1, 0.5, and 0.8 releases 😒) and then install the latest 0.0. Can be tough to update, since it's never clear if there's an update to only the long-lead, and they have to scroll all the way through 😒 But they don't have to set up a separate feed 👍.
-longmain version number: No restrictions (it's never incremented) ✅1.4.0(ABC)1.4.0(ABC)1.3.11.4-next2(ABC)1.3.01.4-next1(ABC)1.2.11.3.11.2.01.3-next20.0-long2104(ABC+XYZ)0.0-long2013(ABC+XYZ)If it's on Azure feeds and we use 0.0 (Alternative choice)
Developers would have to set up a separate Azure feed (slightly annoying 😒) and then select the latest from that feed (selecting latest is easy 👍). Updating is mostly easy, if they have that feed selected, the update will only suggest updates within the long-lead channel, but if they select all feeds or NuGet, it'll still suggest the GAs or previews.
-longmain version number: No restrictions (it's never incremented) ✅1.4.0(ABC)1.4.0(ABC)0.0-long2104(ABC+XYZ)1.3.11.4-next2(ABC)0.0-long2103(ABC+XYZ)1.2.11.4-next1(ABC)0.0-long2102(ABC+XYZ)1.2.01.3.10.0-long2101Concerns
0.0-xxxfeels odd, I'd have the experimental versions be one version ahead, so if1.1is the next GA release, experimental would be1.2Option 1 - Stable, Preview, and Canary channels
What we're doing today (aside from we don't have a Canary channel yet).
🔁 Experimental
🔁 Experimental
What this looks like with features ABC and XYZ from earlier...
1.3 GA1.4 GAABC (1.4)
1.5 GAABC (1.4)
XYZ (1.5)
1.4-next11.4-next2ABC (1.4)
XYZ (1.5)
1.4-next3ABC (1.4)
XYZ (1.5)
1.5-next1ABC (1.4)
XYZ (1.5)
1.5-next2ABC (1.4)
XYZ (1.5)
1.5-next3ABC (1.4)
XYZ (1.5)
1.6-next1ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April...
1.4(ABC)1.5-next1(ABC+XYZ)1.31.4(ABC)1.21.4-next3(ABC+XYZ)What this looks like for each scenario...
1.4-next3to1.4 GA, we simultaneously release1.5-next1so that "update to latest" always keeps them on the preview channel1.4-next3, to help validate the1.4 GA, however,1.4-next3includes experimental features that won't be in the GA, so they can't really validate what the GA release itself will be like...Option 2 - Stable (with RCs), Preview, and Canary channels
Same as Option 1 but just adding a Release Candidate
RC: ~1 month before GA
🔁 Experimental
🔁 Experimental
What this looks like with features ABC and XYZ from earlier...
1.3 GA1.4-rc1ABC (1.4)
1.4 GAABC (1.4)
1.5-rc1ABC (1.4)
XYZ (1.5)
1.5 GAABC (1.4)
XYZ (1.5)
1.4-next21.4-next3ABC (1.4)
XYZ (1.5)
1.5-next1ABC
XYZ (1.5)
1.5-next2ABC (1.4)
XYZ (1.5)
1.5-next3ABC (1.4)
XYZ (1.5)
1.6-next1ABC (1.4)
XYZ (1.5)
1.6-next2ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April...
1.4(ABC)1.5-next2(ABC+XYZ)1.31.5-next1(ABC+XYZ)1.21.4(ABC)1.11.4-rc1(ABC)1.01.4-next3(ABC+XYZ)What this looks like for each scenario...
1.4-next4to1.4-rc1or1.4 GA, we simultaneously release1.5-next1with1.4-rc1so that "update to latest" always keeps them on the preview channel1.4-rc1, to help validate the1.4 GA.1.5-next1, so developers have to explicitly select an "older" oneOption 3.1.1 - Stable, Preview, Experimental (0.0), and Canary channels
Basically the same as Option 2... "Stable RCs" become "Stable previews" (it's a preview of the upcoming release), "Previews" become "Experimental", and we ship the "RCs" monthly. In this case, the
1.4-nextXis always more representative of what is planned to be in 1.4, no features planned to be in 1.5 will be part of the 1.4 preview.Additionally, we number the experimental versions as 0.0, since they contain features that might be part of 1.5 or 1.7... they're not specific to a specific version, they're reflective of "what we currently have".
(+servicing)
🔁 Experimental
🔁 Experimental
What this looks like with features ABC and XYZ from earlier...
1.3.0 GA1.3.11.4 GAABC (1.4)
1.4.1ABC (1.4)1.5 GAABC (1.4)
XYZ (1.5)
1.4-next11.4-next2ABC (1.4)
1.5-next1ABC (1.4)
1.5-next2ABC (1.4)
XYZ (1.5)
0.0-long21010.0-long2102ABC (1.4)
XYZ (1.5)
0.0-long2103ABC (1.4)
XYZ (1.5)
0.0-long2104ABC (1.4)
XYZ (1.5)
0.0-long2105ABC (1.4)
XYZ (1.5)
0.0-long2106ABC (1.4)
XYZ (1.5)
0.0-long2107ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April...
1.4.0(ABC)1.4.0(ABC)1.3.11.4-next2(ABC)1.3.01.4-next1(ABC)1.2.11.3.11.2.01.3-next20.0-long2104(ABC+XYZ)0.0-long2013(ABC+XYZ)What this looks like for each scenario...
previewrelease0.0-long2103to1.4-next1or1.4 GA.1.4-next3, to help validate the1.4 GA.Option 3.1.2 - Stable, Preview, Experimental (X.X), and Canary channels
Same as 3.1.2, but we version the Experimental packages too
(+servicing)
🔁 Experimental
🔁 Experimental
What this looks like with features ABC and XYZ from earlier...
1.3.0 GA1.3.11.4 GAABC (1.4)
1.4.1ABC (1.4)1.5 GAABC (1.4)
XYZ (1.5)
1.4-next11.4-next2ABC (1.4)
1.5-next1ABC (1.4)
1.5-next2ABC (1.4)
XYZ (1.5)
1.3-long31.4-long1ABC (1.4)
XYZ (1.5)
1.4-long2ABC (1.4)
XYZ (1.5)
1.4-long3ABC (1.4)
XYZ (1.5)
1.5-long1ABC (1.4)
XYZ (1.5)
1.5-long2ABC (1.4)
XYZ (1.5)
1.5-long3ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April... (we need to make sure we never publish a higher number experimental without a preview of the same number existing, so devs don't accidently update to experimental).
1.4.0(ABC)1.4.0(ABC)1.3.11.4-next2(ABC)1.3.01.4-next1(ABC)1.2.11.4-long3(ABC+XYZ)1.2.01.4-long2(ABC+XYZ)1.1.11.4-long1(ABC+XYZ)1.1.01.3.1(ABC+XYZ)What this looks like for each scenario...
previewrelease1.4-long1to1.4-next1or1.4 GA.1.4-next3, to help validate the1.4 GA.Option 3.2.1 - Stable, Preview, Experimental 0.0 (on Azure feeds), and Canary channels
Same as Option 3.1 except we distribute the Experimentals on Azure feeds, so public NuGet remains only GA releases and previews of the GA releases. See what this would look like on our roadmap.
(+servicing)
🔁 Experimental
🔁 Experimental
What this looks like with features ABC and XYZ from earlier...
1.3.0 GA1.3.11.4 GAABC (1.4)
1.4.1ABC (1.4)1.5 GAABC (1.4)
XYZ (1.5)
1.4-next11.4-next2ABC (1.4)
1.5-next1ABC (1.4)
1.5-next2ABC (1.4)
XYZ (1.5)
0.0-long21010.0-long2102ABC (1.4)
XYZ (1.5)
0.0-long2103ABC (1.4)
XYZ (1.5)
0.0-long2104ABC (1.4)
XYZ (1.5)
0.0-long2105ABC (1.4)
XYZ (1.5)
0.0-long2106ABC (1.4)
XYZ (1.5)
0.0-long2107ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April...
1.4.0(ABC)1.4.0(ABC)0.0-long2104(ABC+XYZ)1.3.11.4-next2(ABC)0.0-long2103(ABC+XYZ)1.2.11.4-next1(ABC)0.0-long2102(ABC+XYZ)1.2.01.3.10.0-long2101What this looks like for each scenario...
1.4-next3, to help validate the1.4 GA.Option 3.2.2 - Stable, Preview, Experimental X.X (on Azure feeds), and Canary channels
Same as Option 3.2.1 except we version experimental rather than using
0.0...(+servicing)
🔁 Experimental
🔁 Experimental
What this looks like with features ABC and XYZ from earlier...
1.3.0 GA1.3.11.4 GAABC (1.4)
1.4.1ABC (1.4)1.5 GAABC (1.4)
XYZ (1.5)
1.4-next11.4-next2ABC (1.4)
1.5-next1ABC (1.4)
1.5-next2ABC (1.4)
XYZ (1.5)
1.4-long11.4-long2ABC (1.4)
XYZ (1.5)
1.4-long3ABC (1.4)
XYZ (1.5)
1.5-long1ABC (1.4)
XYZ (1.5)
1.5-long2ABC (1.4)
XYZ (1.5)
1.5-long3ABC (1.4)
XYZ (1.5)
1.6-long1ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April...
1.4.0(ABC)1.4.0(ABC)1.5-long1(ABC+XYZ)1.3.11.4-next2(ABC)1.4-long3(ABC+XYZ)1.3.01.4-next1(ABC)1.4-long2(ABC+XYZ)1.2.11.3.11.4-long1What this looks like for each scenario...
1.4-next3, to help validate the1.4 GA.What do other products have for release channels?
Microsoft Edge
Chromium
React
17.0.3, etc0.0.0-b48b38af60.0.0-longerimental-b48b38af6Xamarin Forms
Flutter
Visual Studio
Discarded options
Option 4 - Experimental flags with Stable, Preview, and Canary channels
Moved to discarded since interest in shipping experimental features (under flags) in GA is not appealing to most
We use experimental flags so that experimental features can still be shipped in a stable release.
🔁 Experimental
🔁 Experimental
🔁 Experimental
What this looks like with features ABC and XYZ from earlier (* indicates must call experimental unlock API first before using)...
1.3 GA1.4 GAABC (1.4)
XYZ* (1.5)
1.5 GAABC (1.4)
XYZ (1.5)
1.4-next1ABC* (1.4)
XYZ* (1.5)
1.4-next2ABC (1.4)
XYZ* (1.5)
1.5-next1ABC (1.4)
XYZ* (1.5)
1.5-next2ABC (1.4)
XYZ (1.5)
What you'd see in NuGet Package Manager in April...
1.4(ABC+XYZ*)1.5-next1(ABC+XYZ*)1.31.4(ABC+XYZ*)1.21.4-next2(ABC+XYZ*)1.11.4-next1(ABC*+XYZ*)1.01.3What this looks like for each scenario...
1.4-next3, and ensures they aren't calling any experimental APIs, to help validate the1.4 GA.Beta Was this translation helpful? Give feedback.
All reactions