Skip to content

Conversation

mthalman
Copy link
Member

This document provides guidance for Linux distribution maintainers on source building .NET SDK feature band branches of the VMR. It covers bootstrapping and ongoing servicing workflows when building multiple SDK feature bands.

Fixes #5354

@mthalman mthalman requested review from a team, MichaelSimons, marcpopMSFT and mmitche October 15, 2025 17:48
@mthalman mthalman requested a review from a team as a code owner October 15, 2025 17:48
Comment on lines 275 to 276
- PSB artifacts: Source-built previous N.0.2xx release
- SDK: Source-built previous N.0.2xx release
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mmitche / @MichaelSimons

Is this what we agreed on for 3xx? You would never use 3xx SDK or artifacts to build the next version? You would always use 2xx?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is my understanding.

Copy link
Member

@MichaelSimons MichaelSimons left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice write-up. There is a lot of good content here.


Enhanced SDK tooling that ships with Visual Studio updates:

- **Content**: Contains only SDK tooling differences from 1xx band (subset
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not fond of including "differences" here. It can be interpreted that source deltas are the only thing contained. The entire SDK tooling is included not just the differences.


### 3xx Band Build Requirements

- **Bootstrap (any version)**: Two-stage process using Microsoft source-built
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is confusing IMO because you really don't bootstrap 3xx at all. You are always using 2xx artifacts/sdk to build 3xx. The bootstrap here really applies to 2xx.


- **Bootstrap (any version)**: Two-stage process using Microsoft source-built
2xx artifacts + Microsoft 2xx SDK + prep script
- **Initial Release (N.0.200)**: Latest source-built 1xx artifacts + Latest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by latest? Latest released or latest as in tip? The document should be consistent in the terminology used - e.g. current/previous

- Shared component artifacts: Source-built current N.0.1xx release
- PSB artifacts: Source-built previous N.0.2xx release
- SDK: Source-built previous N.0.2xx release
- **Bootstrap (N.0.300)**:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not seeing the value in bootstrapping 3xx as it never produces a true source built product. To me you would bootstrap 2xx and then do a normal 3xx build.

# Final source-built outputs available in artifacts/x64/Release/
```

```mermaid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to have a more consistent naming of the Build Process inputs that map more closely to the build script? e.g. sdk/packages/shared-components or with-sdk/with-packages/with-shared-components?

# Final source-built outputs available in artifacts/x64/Release/
```

```mermaid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to include 2xx in the Microsoft-built SDK and artifacts nodes.

- PSB artifacts: Source-built previous N.0.2xx release
- SDK: Source-built previous N.0.2xx release

### Scenario 1: 1xx Band Bootstrap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this doc as being a useful reference at times. Because of that I think have a table of contents would be useful mainly for these scenarios.

- Include shared runtime and foundational components that all feature bands
depend on

## Feature Band Characteristics
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually this should reference SDK documentation the feature bands which isn't finalized yet.

- PSB artifacts: Source-built previous N.0.2xx release
- SDK: Source-built previous N.0.2xx release

### Scenario 1: 1xx Band Bootstrap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also see the 'Input Artifacts Summary' as being redundant with these scenarios. IMO the summary should be removed. When I read it I wanted to see this information along side the contents in the summary.

- PSB artifacts: Source-built previous N.0.2xx release
- SDK: Source-built previous N.0.2xx release

### Scenario 1: 1xx Band Bootstrap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO scenario x in the headings doesn't add value. The descriptive name is what is useful.

@MichaelSimons MichaelSimons requested a review from a team October 15, 2025 22:21
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.

Define official documentation for feature band building

2 participants