-
Notifications
You must be signed in to change notification settings - Fork 138
Expand file tree
/
Copy pathDirectory.Build.props
More file actions
121 lines (105 loc) · 7.5 KB
/
Copy pathDirectory.Build.props
File metadata and controls
121 lines (105 loc) · 7.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
<Project>
<PropertyGroup>
<NuGetAudit>true</NuGetAudit>
<NuGetAuditMode>all</NuGetAuditMode>
<NuGetAuditLevel>low</NuGetAuditLevel>
</PropertyGroup>
<!-- Treat all compiler and analyzer warnings as errors so the build stays clean and regressions
surface at build time instead of in review. This binds test projects too: the MTP0001 /
xUnit1051 NoWarn carve-out they once needed is gone, because the suites now satisfy both
rules outright. -->
<PropertyGroup>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
<!-- Unions are a C# 15 feature, so the version is named rather than left to the SDK. Named rather
than "latest" because "latest" moves with the toolchain: the day C# 16 arrives, a construct
from it compiles here without anyone deciding that, and the build starts requiring an SDK
nobody chose. Below 15 the compiler does not know the keyword and reads the declaration as an
identifier, so the failure is a run of CS0106 about modifiers rather than anything naming a
language version.
This deliberately stops short of "preview", which the file carried while the feature was
behind it: preview admits every other unfinished feature as well, and one used by accident is
one that can change under us before it ships. -->
<PropertyGroup>
<LangVersion>15.0</LangVersion>
</PropertyGroup>
<!-- MinVer derives PackageVersion / AssemblyVersion / FileVersion / InformationalVersion
from git tags. The latest tag sets the base; commits since it bump the patch and
append the height and the pre-release suffix.
MinVerMinimumMajorMinor names the line dev builds publish under. It moves when a release is
CUT, never while one is being prepared: until the tag exists, the work on these branches IS
that release, and a consumer floating on its range is waiting for exactly this work. Moved
early, the range they float on stops being filled by anybody and the fix they are waiting for
silently never arrives - the restore keeps resolving, to the last build before the move.
A line ABANDONED rather than cut is the other way it moves, and the reason is the same read
backwards: nobody is waiting for a release that will not happen, so leaving the property
behind would publish this work under a number it will never ship as. Before moving it that
way, look for consumers floating on the abandoned range - a range with none is why the move
costs nothing, and a range with some is the case the paragraph above is about.
MinVerDefaultPreReleaseIdentifiers replaces the default "alpha.0" with "dev.0", so the
range a consumer floats on reads MAJOR.MINOR.0-dev.* and cannot be confused with an alpha. A
tagged release drops the suffix by itself.
No version number is written in this comment on purpose: a number repeated in prose beside
the property it describes goes stale without anything noticing. The run summary in
.github/workflows/publish-dev-builds.yml no longer repeats it either - it derives the range
from the version the build produced, so nothing there can contradict this property. What
that workflow still carries is a worked EXAMPLE in its header comment, which a bump should
follow but which no consumer ever reads.
MinVer reads NO tag in this repository, and that is a consequence of choices worth
knowing rather than a fault to fix in passing. Release tags are two-part and v-prefixed
(v2.3): MinVerTagPrefix is unset, so the prefix is never stripped, and even stripped, "2.3"
is not SemVer and would still be refused. They also sit on master, which is not an ancestor
of develop, and MinVer walks the history of the branch being built.
Nothing depends on it reading them. A release takes its version from the workflow input via
MinVerVersionOverride, and a dev build takes it from this property. What it does mean is
that the number after dev.0 counts from the ROOT COMMIT rather than from the last release.
It is the FIRST-PARENT distance, which is checkable at any commit rather than quotable:
the height plus one is the number of commits on the first-parent chain from HEAD, exactly,
at every commit measured. (The command is git rev-list counting first parents only; it
cannot be written out here, because an XML comment may not contain a double hyphen and a
props file that does breaks every project that imports it.)
So it is not the count of everything reachable - the two differ by every commit that came
in on the side of a merge, which here is over two hundred. Written as the relationship
rather than as numbers on purpose: a height quoted in a comment is stale on the next push,
and two earlier attempts at this sentence were wrong precisely because they quoted.
Setting MinVerTagPrefix alone would not help and does not leave the rest alone: seven older
tags ARE three-part (v1.0.100, v1.1.0, v1.2.0, v1.3.0, v1.3.1, v1.6.0, v2.0.1), and v2.0.1
is reachable from master - measured, setting the prefix makes master's height SMALLER, so its
published number moves BACKWARDS, which is the direction that collides silently. How much
smaller is not a first-parent distance any more and is deliberately not stated here: v2.0.1
is not on master's first-parent chain at all, so once a tag is read the height stops being
measured along that chain. The two four-part tags are not part of that risk: measured, MinVer
does not read a four-part tag either.
The run summary derives all three parts of the version it prints rather than re-asserting a
zero patch, which is right whatever the tags do: NuGet floats only the release label, so a
range written as MAJOR.MINOR.0-dev.* cannot resolve a MAJOR.MINOR.1 build. -->
<PropertyGroup>
<MinVerMinimumMajorMinor>3.0</MinVerMinimumMajorMinor>
<MinVerDefaultPreReleaseIdentifiers>dev.0</MinVerDefaultPreReleaseIdentifiers>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="MinVer" PrivateAssets="all" />
</ItemGroup>
<!-- SonarCloud's C# ruleset runs locally at build time via this analyzer.
Closes the feedback loop so Sonar findings surface in `dotnet build`
instead of waiting for a CI scan. PrivateAssets=all keeps the analyzer
out of the NuGet graph we ship to consumers. -->
<ItemGroup>
<PackageReference Include="SonarAnalyzer.CSharp">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>analyzers; build; buildtransitive</IncludeAssets>
</PackageReference>
</ItemGroup>
<!-- The house rules the compiler refuses, taken from src/Abblix.Analyzers the way every other Abblix
repository takes them from its package: the analyzer assembly, the banned-member list and its
severity. The analyzer project is excluded from its own reference. -->
<ItemGroup Condition="'$(MSBuildProjectName)' != 'Abblix.Analyzers'">
<ProjectReference Include="$(MSBuildThisFileDirectory)src/Abblix.Analyzers/Abblix.Analyzers.csproj"
OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
<PackageReference Include="Microsoft.CodeAnalysis.BannedApiAnalyzers">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>analyzers; build; buildtransitive</IncludeAssets>
</PackageReference>
</ItemGroup>
<Import Project="$(MSBuildThisFileDirectory)src/Abblix.Analyzers/buildTransitive/Abblix.Analyzers.props" />
</Project>