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

replace default pre-release phase with default pre-release identifiers #839

Merged
merged 1 commit into from
Nov 23, 2022

Conversation

adamralph
Copy link
Owner

@adamralph adamralph commented Nov 11, 2022

Use case(s)

When the default pre-release identifiers, alpha.0, which are used to version post-RTM commits which are not tagged with a version, do not match the desired pre-release identifier conventions. For example, the desired conventions may not allow for alpha.1 as the initial pre-release or they may have a different number of identifiers.

Description

By setting MinVerDefaultPreReleaseIdentifiers, you can change the default pre-release identifiers from alpha.0, to something else, such as preview.0, or preview.0.0.

E.g.

<PropertyGroup>
  <MinVerDefaultPreReleaseIdentifiers>preview.0.0</MinVerDefaultPreReleaseIdentifiers>
</PropertyGroup>

Alternatives

  • Ignore, or workaround, the fact that the versions produced between an RTM tag and the next tag do match your desired pre-release identifier conventions.
  • Tag the commit immediately following the RTM tag with a version with sentinel pre-release identifiers. For example, tag the commit immediately following the 1.0.0 RTM tag with 1.0.0-preview.0.0.

Additional context

See #796 (reply in thread).

MinVerDefaultPreReleaseIdentifiers supersedes MinVerDefaultPreReleasePhase, which has been deprecated, and will be removed in the next major version.

@adamralph adamralph added the enhancement New feature or request label Nov 11, 2022
@adamralph adamralph force-pushed the default-pre-release-identifiers branch from c90edf8 to 8c478a5 Compare November 15, 2022 09:33
@adamralph adamralph added this to the 4.3.0 milestone Nov 23, 2022
@adamralph adamralph force-pushed the default-pre-release-identifiers branch from 8c478a5 to 8276d73 Compare November 23, 2022 16:18
@adamralph adamralph force-pushed the default-pre-release-identifiers branch from 8276d73 to 7f2ea07 Compare November 23, 2022 16:31
@adamralph adamralph marked this pull request as ready for review November 23, 2022 16:49
@adamralph adamralph enabled auto-merge November 23, 2022 16:50
@adamralph adamralph merged commit c0206b5 into main Nov 23, 2022
@adamralph adamralph deleted the default-pre-release-identifiers branch November 23, 2022 17:52
@adamralph
Copy link
Owner Author

@iampluque @lonix1 with reference to #796, I've released this in 4.3.0-beta.1. Please feel free to give it a try.

@adamralph adamralph mentioned this pull request Nov 25, 2022
11 tasks
ivarne added a commit to Altinn/app-lib-dotnet that referenced this pull request Oct 16, 2023
adamralph/minver#839
MinVerDefaultPreReleasePhase -> MinVerDefaultPreReleaseIdentifiers
ivarne added a commit to Altinn/app-lib-dotnet that referenced this pull request Oct 26, 2023
adamralph/minver#839
MinVerDefaultPreReleasePhase -> MinVerDefaultPreReleaseIdentifiers
ivarne added a commit to Altinn/app-lib-dotnet that referenced this pull request Nov 13, 2023
* MinVer update

adamralph/minver#839
MinVerDefaultPreReleasePhase -> MinVerDefaultPreReleaseIdentifiers

* Don't warn for [Obsolete] api usage or missing XML doc in test projects

* Enable nullable in options controller

The `[FromQuery]` `?language=` parameter was optional without nullable
reference types, but now became required causing a `BadRequest` in tests.
It was not decorated as nullable, so a quick fix is to supply a default value
of "nb".

Other potential resolutions would be
* Update the interface so that language is declared nullable for IAppOptionsProvider
* Change the public app API, so that language becomes a required get parameter.

* Fix all the easy nullability warnings in Controllers

Note that enabeling nullable on controllers makes non nullable
parameters required and causes additional BadRequest responses

* Change behaviour of SecretsLocalClient to throw exception like the client backed by KeyVault

* Fix nullability warnings in MulipartRequestReader

* Update sonarColud comment

* Declare DataController with [ApiController] to automatically trigger bad request

Also add test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant