Releasing dotnet and sql packages

Bulb

I am trying to do a release of an (internal) application that has a bunch of components in different languages and frameworks. For each component I want a build that sets the version in any relevant project files, builds, commits and tags the release, and then adds a pre-release version and commits again. That seems to be the most reasonable way to work with semver.

For the Java parts there is the maven release plugin, which does exactly that.
For the front-end we have npm version. It has to be called a second time to set the pre-release version afterwards, but that's good enough.

That leaves four kinds of artifacts:

The DotNET service. It is a bunch of .csproj projects built with the dotnet utility in docker. I found one can put a Version property, or a VersionPrefix+VersionSuffix pair, in the .csproj and they'll be used for the package version (it is an application, so I don't care about the assembly version much).
The VS Database project, i.e. a .sqlproj. Is there even any best practice for versioning those?
The helm charts. I am prepared to give up and cobble it up in python. There is a bunch of them, plus the following item, so I need some scripting in that repo either way. I wouldn't be angry if there was something already prepared though.
The ARM templates. I am pretty sure there isn't even a best practice for this, and unlike for YAML (in the helm templates) where I can at least do structure-aware format-preserving edit with ruamel.yaml, I didn't find anything for JSONC. Is there at least something for that?

Does any of you who work with .NET know a tool or common practice for bumping the versions there? Or for any of the other tools, but the .NET, including the database project are the ones I think there should be something, but can't find it.

JBert

@Bulb With regards to the maven release plugin: when I used it I would only do mvn release:prepare. Then later on I found that there's a similar plugin which doesn't even do the commit so that you could run it locally or on the build server.

Here's the Windows Batch file with which I've wrapped it:

SETLOCAL
set version=%1
shift
if %1.==. goto startmvn
set params=%1
:loop
shift
if %1.==. goto startmvn
set params=%params%
goto loop
:startmvn
mvn org.codehaus.mojo:versions-maven-plugin:2.0:set -DnewVersion=%version% -DgenerateBackupPoms=false %params%

As for .NET...

All our build pipelines include some bits of PowerShell to do a find/replace on certain files. If the placeholder is unique enough then you can use it in pretty much any kind of file.

Bulb

@JBert said in Releasing dotnet and sql packages:

find/replace on certain files

The replacing is the easier part. The fiddling with the version is the harder one.

JBert

@Bulb Aaah, I missed that part.

Sorry, can't really help you then. Our source code doesn't really contain a version (well, it has either a default or a placeholder).

The build then has a mandatory "version" variable to pass the major, minor and bugfix versions. No auto-increments are done...

Parody

Bah. I know I had a VS plugin in the last .NET project where I had to worry about such things that would automatically set the build numbers based the template you gave it, but I can't remember what it was called. I know the build number scheme we used was Major.Minor.MoreMinor.BuildCode, with BuildCode being the year and the day of the year (so April 2nd, 2021 would be 21092). I'm sure that's a big help. :)

robo2

@Bulb I've been looking at https://gitversion.net/ together with the auto generated assembly info attributes performed in .net sdk style projects, with the basic version information set in a Directory.Build.props in the root of the src tree. In the end I kept the D.B.p file, but updated it through scripts. It was a bit hard to use gitversion if you're not using git (yet)...

Bulb

@robo2 Hm…

I used to strongly prefer taking the version from version control system, not have it written inside the files at all and derive it during the build. Because that can assign a unique ID to every revision, among other things.

But then on the other (mostly-)Java project we had a discussion about this, and the problem is that the standard Maven convention/semver is incompatible with it, because from the version control you can only derive post-versions, but semver only defined pre-versions, and git describe isn't up to the task. So we went the mvn release-route. And similar thing exits for other languages, e.g. cargo-release.

I did notice gitversion before. I promptly forgot about it again, because

It does not have reasonably simple installation instructions. Yes, I am now asking about .NET, but the other components are Java, Helm and such, and everything, except the database project, is built on Linux. There is a docker with it, but docker containers don't compose, so it does not really help.
The documentation is fairly convoluted and I had hard time finding some sensible start of it. I had the same problem with the maven release thing, but the Java folks around here already knew that one.

I suppose it would just work for the two dotnet-based projects—well, some manual tweaking required for the database projects anyway. But then I'd have two different workflows and I don't like that. And the Java side insists on having the version inside the project file (it isn't possible to even override with a plugin—reliably).

dkf

@Bulb said in Releasing dotnet and sql packages:

And the Java side insists on having the version inside the project file

That's necessary in a multi-module project (which most non-trivial projects are) so that the build system can know when it has found all its bits and pieces correctly. There is tooling for stamping the version number into the right places including the version control system (and you can also stamp in a build number if you want, e.g. the git commit ID or the date, or some derivative thereof).

Having all this complexity does mean that other scenarios are supported, so it's not all bad. It's just that you can't achieve all conceivable objectives; some combinations of desirables just won't ever work in an even half-sane build system, so there's always going to be variation.

Kamil Podlesak

@Bulb said in Releasing dotnet and sql packages:

And the Java side insists on having the version inside the project file (it isn't possible to even override with a plugin—reliably).

Just for the record - this is definitely not needed with gradle, which can load version from anywhere (I am constructing it from git hash in some projects; edit: only for rc and release builds, even).

Of course, converting maven build to gradle might be non-trivial task. I can recommend it, but not everywhere. Front-page contributors should get maven and nothing more.

Bulb

@dkf To know it has found all the parts correctly it needs the version in the built packages, and in the dependency references (where you can have a range, though we tend to always have fixed versions). But it could read the version of the package being built from some other where. But it can't. There is a git commit id plugin that can fill the git version in a bunch of places, but it does not reliably work for the package version.

@Kamil-Podlesak said in Releasing dotnet and sql packages:

@Bulb said in Releasing dotnet and sql packages:
Just for the record - this is definitely not needed with gradle, which can load version from anywhere (I am constructing it from git hash in some projects; edit: only for rc and release builds, even).

Something something about habit and iron shirts. The main java developer knows gradle would be better, but he created the projects using the maven template and the warthog has been kneeling ever since.