Prelease Version Strategies

_These are raw notes from a few collaboration meetings I have had on the subject._

# Prelease

1. Incremental prerelease
2. Major version bump

We want a way to configure it that every time a commit is created, we publish on that tag.

### prereleases
main branch is 2.1.0
=> open feat A branch with a minor bump => 2.2.0-feat-a.0 (dirty publish with the tag name, hit registry to get existing tags)
=> open feat B branch with a minor bump => 2.2.0-feat-b.0 (dirty publish with the tag name, hit registry to get existing tags)

main branch could get a prelease on `next` or similar off of HEAD

### major version bump
- Config value flip
- config value to prevent major version

### process into using this

0. Previews by default without any change files on main branch.
1. Next turn it on for PRs? First step onramp could be opt into prelease on each PR commit (opt into prelease?). (Every package gets a bump if no changes exist yet.)
2. Next step would be with PRs and change files.

semver: https://semver.org/

> 9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.

> 10. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.

# Language Version Numbering

## dotnet

Parsing: https://www.npmjs.com/package/xml-js

- https://devblogs.microsoft.com/devops/versioning-nuget-packages-cd-1/
- https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/versioning
- https://www.mytechramblings.com/posts/centrally-manage-nuget-versions/
- https://docs.microsoft.com/en-us/nuget/concepts/package-versioning
- https://saebamini.com/how-to-version-your-net-nuget-packages-libraries-and-assemblies-azure-yaml-pipelines-example-using-net-core-cli/

## dart/flutter

Parsing: https://www.npmjs.com/package/js-yaml

- https://dart.dev/tools/pub/versioning

The issue contains raw meeting notes but names no repository files, tests, or implementation entry points. Start by reviewing the existing release and versioning flow, then use the SemVer and language-versioning references to turn the proposed prerelease and major-version options into agreed requirements; done should include a decided strategy and an identified implementation plan.

Written by the indexing model from the issue text.