BranchesTags

Repository files navigation

.NET Versions

This repo contains information about the various component versions that ship with .NET Core.

build-info

The directory that holds information about the current builds that are available for each repo.

Structure

At the top-level, the directories are organized in the same way GitHub organizes repos. Here is the pattern:

/build-info/<owner>/<repo>

ex. /build-info/dotnet/corefx

Underneath the <repo>, we list the <channel> for the build.

Channels

At a high-level, a channel is a place to store the outputs of a build. A product defines a set of channels that it produces outputs for, and then as builds are executed, the build outputs are put into one or more channels.

Examples of channels using the dotnet/corefx repo:

  • master
  • release/1.0.0
  • release/1.0.0-rc2
  • release/1.0.1
  • etc

Consumers can subscribe to a channel of a repo, and consume the outputs.

It is important to recognize that while channels usually map closely to official branches in a repo, they are not in a one-to-one relationship. One goal of the channel concept is that consumers of your repo are agnostic to your underlying branch structure. Normally consumers will want to consume a version "x.y.z" build outputs, they don't care what branch they come from. And furthermore, the branch they come from often changes, especially at the end of a release. For example, at one point the dotnet/corefxmaster branch was producing builds for the "1.0.0" release, while the "1.0.0-rc2" release was stabilizing. But then later, when the "1.0.0" release was stabilizing, a new branch release/1.0.0 was created and that branch started producing builds for that channel. Consumers don't want to have to switch channels, just because a repo switched branches.

This reasoning shows why it is possible for a single branch to put its builds into multiple channels. If a consumer always wanted to track the "latest and greatest" builds from the dotnet/corefx repo, they could subscribe to the master channel, and they would always get the newest builds with the latest code and all the bug fixes. However, there are other consumers that want to strictly get the "current stabilizing release + 1" bits from dotnet/corefx, but not necessarily always from master. For example, while "1.0.0-rc2" is stabilizing, I want to consume the "1.0.0" release bits and continue to consume them even when "1.0.0" branches into a release branch.

Build Pointers

Each channel directory contains files about each build it wants to track. This can be referred to as "Build Pointers". Typical builds that are tracked are:

  • Latest
  • LKG (or Last Known Good)
  • Release (The build that was released from this channel)

But each owner/repo/channel can define builds and build names that make sense for them to track.

Renaming

Keep in mind that these names are public, and consumers will be taking dependencies on channel names and build pointer names. You should consider renaming these folders/files like you would any other breaking change (it needs plenty of communication).

Suggestions

If NuGet packages are being produced by your repo, a suggestion is to list the URL of the myget/nuget feed where consumers can get those NuGet packages along with the package Ids and Versions. This allows for automation to find these packages without having to hard-code the feed themselves.

Maestro

An application that coordinates between multiple repositories. It has the ability to automate any process that requires cross-repo communication. For example, when a new LKG build of one repo is available, it can signal any dependent repos to start using this new build.

About

This repo contains information about the various component versions that ship with .NET Core.

Resources

Readme
MIT license

Code of conduct

Code of conduct
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Repository files navigation
.NET Versions
This repo contains information about the various component versions that ship with .NET Core.
build-info
The directory that holds information about the current builds that are available for each repo.
Structure
At the top-level, the directories are organized in the same way GitHub organizes repos. Here is the pattern:
/build-info/<owner>/<repo>
ex. /build-info/dotnet/corefx
Underneath the <repo>, we list the <channel> for the build.
Channels
At a high-level, a channel is a place to store the outputs of a build. A product defines a set of channels
that it produces outputs for, and then as builds are executed, the build outputs are put into one or more
channels.
Examples of channels using the dotnet/corefx repo:
  • master
  • release/1.0.0
  • release/1.0.0-rc2
  • release/1.0.1
  • etc
Consumers can subscribe to a channel of a repo, and consume the outputs.
It is important to recognize that while channels usually map closely to official branches in a repo, they
are not in a one-to-one relationship. One goal of the channel concept is that consumers of your repo are
agnostic to your underlying branch structure. Normally consumers will want to consume a version "x.y.z"
build outputs, they don't care what branch they come from. And furthermore, the branch they come from often changes,
especially at the end of a release. For example, at one point the dotnet/corefxmaster branch was producing
builds for the "1.0.0" release, while the "1.0.0-rc2" release was stabilizing. But then later, when the "1.0.0" release
was stabilizing, a new branch release/1.0.0 was created and that branch started producing builds for that channel.
Consumers don't want to have to switch channels, just because a repo switched branches.
This reasoning shows why it is possible for a single branch to put its builds into multiple channels. If a consumer
always wanted to track the "latest and greatest" builds from the dotnet/corefx repo, they could subscribe to the
master channel, and they would always get the newest builds with the latest code and all the bug fixes. However,
there are other consumers that want to strictly get the "current stabilizing release + 1" bits from dotnet/corefx,
but not necessarily always from master. For example, while "1.0.0-rc2" is stabilizing, I want to consume the "1.0.0"
release bits and continue to consume them even when "1.0.0" branches into a release branch.
Build Pointers
Each channel directory contains files about each build it wants to track. This can be referred to as "Build Pointers".
Typical builds that are tracked are:
  • Latest
  • LKG (or Last Known Good)
  • Release (The build that was released from this channel)
But each owner/repo/channel can define builds and build names that make sense for them to track.
Renaming
Keep in mind that these names are public, and consumers will be taking dependencies on channel names and build pointer names.
You should consider renaming these folders/files like you would any other breaking change (it needs plenty of communication).
Suggestions
If NuGet packages are being produced by your repo, a suggestion is to list the URL of the myget/nuget feed where
consumers can get those NuGet packages along with the package Ids and Versions. This allows for automation to find
these packages without having to hard-code the feed themselves.
Maestro
An application that coordinates between multiple repositories. It has the ability to automate any process
that requires cross-repo communication. For example, when a new LKG build of one repo is available, it can
signal any dependent repos to start using this new build.
About
This repo contains information about the various component versions that ship with .NET Core. 
Resources
Readme
MIT license
Code of conduct
Code of conduct
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
.NET Versions
This repo contains information about the various component versions that ship with .NET Core.
build-info
The directory that holds information about the current builds that are available for each repo.
Structure
At the top-level, the directories are organized in the same way GitHub organizes repos. Here is the pattern:
/build-info/<owner>/<repo>
ex. /build-info/dotnet/corefx
Underneath the <repo>, we list the <channel> for the build.
Channels
At a high-level, a channel is a place to store the outputs of a build. A product defines a set of channels
that it produces outputs for, and then as builds are executed, the build outputs are put into one or more
channels.
Examples of channels using the dotnet/corefx repo:
  • master
  • release/1.0.0
  • release/1.0.0-rc2
  • release/1.0.1
  • etc
Consumers can subscribe to a channel of a repo, and consume the outputs.
It is important to recognize that while channels usually map closely to official branches in a repo, they
are not in a one-to-one relationship. One goal of the channel concept is that consumers of your repo are
agnostic to your underlying branch structure. Normally consumers will want to consume a version "x.y.z"
build outputs, they don't care what branch they come from. And furthermore, the branch they come from often changes,
especially at the end of a release. For example, at one point the dotnet/corefxmaster branch was producing
builds for the "1.0.0" release, while the "1.0.0-rc2" release was stabilizing. But then later, when the "1.0.0" release
was stabilizing, a new branch release/1.0.0 was created and that branch started producing builds for that channel.
Consumers don't want to have to switch channels, just because a repo switched branches.
This reasoning shows why it is possible for a single branch to put its builds into multiple channels. If a consumer
always wanted to track the "latest and greatest" builds from the dotnet/corefx repo, they could subscribe to the
master channel, and they would always get the newest builds with the latest code and all the bug fixes. However,
there are other consumers that want to strictly get the "current stabilizing release + 1" bits from dotnet/corefx,
but not necessarily always from master. For example, while "1.0.0-rc2" is stabilizing, I want to consume the "1.0.0"
release bits and continue to consume them even when "1.0.0" branches into a release branch.
Build Pointers
Each channel directory contains files about each build it wants to track. This can be referred to as "Build Pointers".
Typical builds that are tracked are:
  • Latest
  • LKG (or Last Known Good)
  • Release (The build that was released from this channel)
But each owner/repo/channel can define builds and build names that make sense for them to track.
Renaming
Keep in mind that these names are public, and consumers will be taking dependencies on channel names and build pointer names.
You should consider renaming these folders/files like you would any other breaking change (it needs plenty of communication).
Suggestions
If NuGet packages are being produced by your repo, a suggestion is to list the URL of the myget/nuget feed where
consumers can get those NuGet packages along with the package Ids and Versions. This allows for automation to find
these packages without having to hard-code the feed themselves.
Maestro
An application that coordinates between multiple repositories. It has the ability to automate any process
that requires cross-repo communication. For example, when a new LKG build of one repo is available, it can
signal any dependent repos to start using this new build.
About
This repo contains information about the various component versions that ship with .NET Core. 
Resources
Readme
MIT license
Code of conduct
Code of conduct
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
.NET Versions
This repo contains information about the various component versions that ship with .NET Core.
build-info
The directory that holds information about the current builds that are available for each repo.
Structure
At the top-level, the directories are organized in the same way GitHub organizes repos. Here is the pattern:
/build-info/<owner>/<repo>
ex. /build-info/dotnet/corefx
Underneath the <repo>, we list the <channel> for the build.
Channels
At a high-level, a channel is a place to store the outputs of a build. A product defines a set of channels
that it produces outputs for, and then as builds are executed, the build outputs are put into one or more
channels.
Examples of channels using the dotnet/corefx repo:
  • master
  • release/1.0.0
  • release/1.0.0-rc2
  • release/1.0.1
  • etc
Consumers can subscribe to a channel of a repo, and consume the outputs.
It is important to recognize that while channels usually map closely to official branches in a repo, they
are not in a one-to-one relationship. One goal of the channel concept is that consumers of your repo are
agnostic to your underlying branch structure. Normally consumers will want to consume a version "x.y.z"
build outputs, they don't care what branch they come from. And furthermore, the branch they come from often changes,
especially at the end of a release. For example, at one point the dotnet/corefxmaster branch was producing
builds for the "1.0.0" release, while the "1.0.0-rc2" release was stabilizing. But then later, when the "1.0.0" release
was stabilizing, a new branch release/1.0.0 was created and that branch started producing builds for that channel.
Consumers don't want to have to switch channels, just because a repo switched branches.
This reasoning shows why it is possible for a single branch to put its builds into multiple channels. If a consumer
always wanted to track the "latest and greatest" builds from the dotnet/corefx repo, they could subscribe to the
master channel, and they would always get the newest builds with the latest code and all the bug fixes. However,
there are other consumers that want to strictly get the "current stabilizing release + 1" bits from dotnet/corefx,
but not necessarily always from master. For example, while "1.0.0-rc2" is stabilizing, I want to consume the "1.0.0"
release bits and continue to consume them even when "1.0.0" branches into a release branch.
Build Pointers
Each channel directory contains files about each build it wants to track. This can be referred to as "Build Pointers".
Typical builds that are tracked are:
  • Latest
  • LKG (or Last Known Good)
  • Release (The build that was released from this channel)
But each owner/repo/channel can define builds and build names that make sense for them to track.
Renaming
Keep in mind that these names are public, and consumers will be taking dependencies on channel names and build pointer names.
You should consider renaming these folders/files like you would any other breaking change (it needs plenty of communication).
Suggestions
If NuGet packages are being produced by your repo, a suggestion is to list the URL of the myget/nuget feed where
consumers can get those NuGet packages along with the package Ids and Versions. This allows for automation to find
these packages without having to hard-code the feed themselves.
Maestro
An application that coordinates between multiple repositories. It has the ability to automate any process
that requires cross-repo communication. For example, when a new LKG build of one repo is available, it can
signal any dependent repos to start using this new build.
About
This repo contains information about the various component versions that ship with .NET Core. 
Resources
Readme
MIT license
Code of conduct
Code of conduct
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Repository files navigation
.NET Versions
This repo contains information about the various component versions that ship with .NET Core.
build-info
The directory that holds information about the current builds that are available for each repo.
Structure
At the top-level, the directories are organized in the same way GitHub organizes repos. Here is the pattern:
/build-info/<owner>/<repo>
ex. /build-info/dotnet/corefx
Underneath the <repo>, we list the <channel> for the build.
Channels
At a high-level, a channel is a place to store the outputs of a build. A product defines a set of channels
that it produces outputs for, and then as builds are executed, the build outputs are put into one or more
channels.
Examples of channels using the dotnet/corefx repo:
  • master
  • release/1.0.0
  • release/1.0.0-rc2
  • release/1.0.1
  • etc
Consumers can subscribe to a channel of a repo, and consume the outputs.
It is important to recognize that while channels usually map closely to official branches in a repo, they
are not in a one-to-one relationship. One goal of the channel concept is that consumers of your repo are
agnostic to your underlying branch structure. Normally consumers will want to consume a version "x.y.z"
build outputs, they don't care what branch they come from. And furthermore, the branch they come from often changes,
especially at the end of a release. For example, at one point the dotnet/corefxmaster branch was producing
builds for the "1.0.0" release, while the "1.0.0-rc2" release was stabilizing. But then later, when the "1.0.0" release
was stabilizing, a new branch release/1.0.0 was created and that branch started producing builds for that channel.
Consumers don't want to have to switch channels, just because a repo switched branches.
This reasoning shows why it is possible for a single branch to put its builds into multiple channels. If a consumer
always wanted to track the "latest and greatest" builds from the dotnet/corefx repo, they could subscribe to the
master channel, and they would always get the newest builds with the latest code and all the bug fixes. However,
there are other consumers that want to strictly get the "current stabilizing release + 1" bits from dotnet/corefx,
but not necessarily always from master. For example, while "1.0.0-rc2" is stabilizing, I want to consume the "1.0.0"
release bits and continue to consume them even when "1.0.0" branches into a release branch.
Build Pointers
Each channel directory contains files about each build it wants to track. This can be referred to as "Build Pointers".
Typical builds that are tracked are:
  • Latest
  • LKG (or Last Known Good)
  • Release (The build that was released from this channel)
But each owner/repo/channel can define builds and build names that make sense for them to track.
Renaming
Keep in mind that these names are public, and consumers will be taking dependencies on channel names and build pointer names.
You should consider renaming these folders/files like you would any other breaking change (it needs plenty of communication).
Suggestions
If NuGet packages are being produced by your repo, a suggestion is to list the URL of the myget/nuget feed where
consumers can get those NuGet packages along with the package Ids and Versions. This allows for automation to find
these packages without having to hard-code the feed themselves.
Maestro
An application that coordinates between multiple repositories. It has the ability to automate any process
that requires cross-repo communication. For example, when a new LKG build of one repo is available, it can
signal any dependent repos to start using this new build.
About
This repo contains information about the various component versions that ship with .NET Core. 
Resources
Readme
MIT license
Code of conduct
Code of conduct
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
.NET Versions
This repo contains information about the various component versions that ship with .NET Core.
build-info
The directory that holds information about the current builds that are available for each repo.
Structure
At the top-level, the directories are organized in the same way GitHub organizes repos. Here is the pattern:
/build-info/<owner>/<repo>
ex. /build-info/dotnet/corefx
Underneath the <repo>, we list the <channel> for the build.
Channels
At a high-level, a channel is a place to store the outputs of a build. A product defines a set of channels
that it produces outputs for, and then as builds are executed, the build outputs are put into one or more
channels.
Examples of channels using the dotnet/corefx repo:
  • master
  • release/1.0.0
  • release/1.0.0-rc2
  • release/1.0.1
  • etc
Consumers can subscribe to a channel of a repo, and consume the outputs.
It is important to recognize that while channels usually map closely to official branches in a repo, they
are not in a one-to-one relationship. One goal of the channel concept is that consumers of your repo are
agnostic to your underlying branch structure. Normally consumers will want to consume a version "x.y.z"
build outputs, they don't care what branch they come from. And furthermore, the branch they come from often changes,
especially at the end of a release. For example, at one point the dotnet/corefxmaster branch was producing
builds for the "1.0.0" release, while the "1.0.0-rc2" release was stabilizing. But then later, when the "1.0.0" release
was stabilizing, a new branch release/1.0.0 was created and that branch started producing builds for that channel.
Consumers don't want to have to switch channels, just because a repo switched branches.
This reasoning shows why it is possible for a single branch to put its builds into multiple channels. If a consumer
always wanted to track the "latest and greatest" builds from the dotnet/corefx repo, they could subscribe to the
master channel, and they would always get the newest builds with the latest code and all the bug fixes. However,
there are other consumers that want to strictly get the "current stabilizing release + 1" bits from dotnet/corefx,
but not necessarily always from master. For example, while "1.0.0-rc2" is stabilizing, I want to consume the "1.0.0"
release bits and continue to consume them even when "1.0.0" branches into a release branch.
Build Pointers
Each channel directory contains files about each build it wants to track. This can be referred to as "Build Pointers".
Typical builds that are tracked are:
  • Latest
  • LKG (or Last Known Good)
  • Release (The build that was released from this channel)
But each owner/repo/channel can define builds and build names that make sense for them to track.
Renaming
Keep in mind that these names are public, and consumers will be taking dependencies on channel names and build pointer names.
You should consider renaming these folders/files like you would any other breaking change (it needs plenty of communication).
Suggestions
If NuGet packages are being produced by your repo, a suggestion is to list the URL of the myget/nuget feed where
consumers can get those NuGet packages along with the package Ids and Versions. This allows for automation to find
these packages without having to hard-code the feed themselves.
Maestro
An application that coordinates between multiple repositories. It has the ability to automate any process
that requires cross-repo communication. For example, when a new LKG build of one repo is available, it can
signal any dependent repos to start using this new build.
About
This repo contains information about the various component versions that ship with .NET Core. 
Resources
Readme
MIT license
Code of conduct
Code of conduct
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
.NET Versions
This repo contains information about the various component versions that ship with .NET Core.
build-info
The directory that holds information about the current builds that are available for each repo.
Structure
At the top-level, the directories are organized in the same way GitHub organizes repos. Here is the pattern:
/build-info/<owner>/<repo>
ex. /build-info/dotnet/corefx
Underneath the <repo>, we list the <channel> for the build.
Channels
At a high-level, a channel is a place to store the outputs of a build. A product defines a set of channels
that it produces outputs for, and then as builds are executed, the build outputs are put into one or more
channels.
Examples of channels using the dotnet/corefx repo:
  • master
  • release/1.0.0
  • release/1.0.0-rc2
  • release/1.0.1
  • etc
Consumers can subscribe to a channel of a repo, and consume the outputs.
It is important to recognize that while channels usually map closely to official branches in a repo, they
are not in a one-to-one relationship. One goal of the channel concept is that consumers of your repo are
agnostic to your underlying branch structure. Normally consumers will want to consume a version "x.y.z"
build outputs, they don't care what branch they come from. And furthermore, the branch they come from often changes,
especially at the end of a release. For example, at one point the dotnet/corefxmaster branch was producing
builds for the "1.0.0" release, while the "1.0.0-rc2" release was stabilizing. But then later, when the "1.0.0" release
was stabilizing, a new branch release/1.0.0 was created and that branch started producing builds for that channel.
Consumers don't want to have to switch channels, just because a repo switched branches.
This reasoning shows why it is possible for a single branch to put its builds into multiple channels. If a consumer
always wanted to track the "latest and greatest" builds from the dotnet/corefx repo, they could subscribe to the
master channel, and they would always get the newest builds with the latest code and all the bug fixes. However,
there are other consumers that want to strictly get the "current stabilizing release + 1" bits from dotnet/corefx,
but not necessarily always from master. For example, while "1.0.0-rc2" is stabilizing, I want to consume the "1.0.0"
release bits and continue to consume them even when "1.0.0" branches into a release branch.
Build Pointers
Each channel directory contains files about each build it wants to track. This can be referred to as "Build Pointers".
Typical builds that are tracked are:
  • Latest
  • LKG (or Last Known Good)
  • Release (The build that was released from this channel)
But each owner/repo/channel can define builds and build names that make sense for them to track.
Renaming
Keep in mind that these names are public, and consumers will be taking dependencies on channel names and build pointer names.
You should consider renaming these folders/files like you would any other breaking change (it needs plenty of communication).
Suggestions
If NuGet packages are being produced by your repo, a suggestion is to list the URL of the myget/nuget feed where
consumers can get those NuGet packages along with the package Ids and Versions. This allows for automation to find
these packages without having to hard-code the feed themselves.
Maestro
An application that coordinates between multiple repositories. It has the ability to automate any process
that requires cross-repo communication. For example, when a new LKG build of one repo is available, it can
signal any dependent repos to start using this new build.
About
This repo contains information about the various component versions that ship with .NET Core. 
Resources
Readme
MIT license
Code of conduct
Code of conduct
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Repository files navigation
.NET Versions
This repo contains information about the various component versions that ship with .NET Core.
build-info
The directory that holds information about the current builds that are available for each repo.
Structure
At the top-level, the directories are organized in the same way GitHub organizes repos. Here is the pattern:
/build-info/<owner>/<repo>
ex. /build-info/dotnet/corefx
Underneath the <repo>, we list the <channel> for the build.
Channels
At a high-level, a channel is a place to store the outputs of a build. A product defines a set of channels
that it produces outputs for, and then as builds are executed, the build outputs are put into one or more
channels.
Examples of channels using the dotnet/corefx repo:
  • master
  • release/1.0.0
  • release/1.0.0-rc2
  • release/1.0.1
  • etc
Consumers can subscribe to a channel of a repo, and consume the outputs.
It is important to recognize that while channels usually map closely to official branches in a repo, they
are not in a one-to-one relationship. One goal of the channel concept is that consumers of your repo are
agnostic to your underlying branch structure. Normally consumers will want to consume a version "x.y.z"
build outputs, they don't care what branch they come from. And furthermore, the branch they come from often changes,
especially at the end of a release. For example, at one point the dotnet/corefxmaster branch was producing
builds for the "1.0.0" release, while the "1.0.0-rc2" release was stabilizing. But then later, when the "1.0.0" release
was stabilizing, a new branch release/1.0.0 was created and that branch started producing builds for that channel.
Consumers don't want to have to switch channels, just because a repo switched branches.
This reasoning shows why it is possible for a single branch to put its builds into multiple channels. If a consumer
always wanted to track the "latest and greatest" builds from the dotnet/corefx repo, they could subscribe to the
master channel, and they would always get the newest builds with the latest code and all the bug fixes. However,
there are other consumers that want to strictly get the "current stabilizing release + 1" bits from dotnet/corefx,
but not necessarily always from master. For example, while "1.0.0-rc2" is stabilizing, I want to consume the "1.0.0"
release bits and continue to consume them even when "1.0.0" branches into a release branch.
Build Pointers
Each channel directory contains files about each build it wants to track. This can be referred to as "Build Pointers".
Typical builds that are tracked are:
  • Latest
  • LKG (or Last Known Good)
  • Release (The build that was released from this channel)
But each owner/repo/channel can define builds and build names that make sense for them to track.
Renaming
Keep in mind that these names are public, and consumers will be taking dependencies on channel names and build pointer names.
You should consider renaming these folders/files like you would any other breaking change (it needs plenty of communication).
Suggestions
If NuGet packages are being produced by your repo, a suggestion is to list the URL of the myget/nuget feed where
consumers can get those NuGet packages along with the package Ids and Versions. This allows for automation to find
these packages without having to hard-code the feed themselves.
Maestro
An application that coordinates between multiple repositories. It has the ability to automate any process
that requires cross-repo communication. For example, when a new LKG build of one repo is available, it can
signal any dependent repos to start using this new build.
About
This repo contains information about the various component versions that ship with .NET Core. 
Resources
Readme
MIT license
Code of conduct
Code of conduct
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages