Add suffix to version without it showing up as a prerelease
I'm writing a lib that wraps a bunch of external GRPC APIs and exposes them via the same interface. They individually have minor differences so I create binding for each of them.
There's one package per external API so users can selectively install only the required ones e.g.
Cosm.Net.Composable
Cosm.Net.Gaia
etc
Now I have my own versioning that is basically the features that my abstraction provides which I just use the normal C# versioning for.
But there's also the version of the API that is being wrapped which can change (including breaking changes). I'd like to have that version in the package version as well so I can push a new package if that changes without having to change the version of all my packages.
e.g.
Cosm.Net.Composable 1.1.0-composable-v.6.5.0
Cosm.Net.Gaia 1.1.0-gaia-v15.1.0
These versions are considered prereleases tho, even tho they are not meant to be. Is there a flag I can set during build or a different naming convention I can use to avoid this?
13 Replies
I'm not exactly sure what you're trying to do, using three different versioning systems with their very own rotations in a single package?
That's why we use the
Major.Minor.Build.Revision versioning, or, if it doesn't suits you, a very common other versioning goes by using the builddate 2024.4.3, both are capable of using appendices for alpha/beta/etc. releases like 2024.4.3-beta1 or 10.4.3.4-beta1.
For the dependecies, you don't need to use the autogenerated nuspec (it's now completly in the background, when using modern tempalte of csproj [generated out of the attributes]). You can setup a very own nuspec and create packages with it, as long you're using nuget as the package feed.
However, be warned, this can easily lead to confusion and let's you get stuck in DLL-Hell.Well I would use
Major.Minor.Build.Revision if there was no external thing involved here.
These external APIs change all the time, I'm not going to be there to always update the lib accordingly (and its not needed as 99% of the time those are not breaking anything either way)
But I wanna clearly communicate with the versioning which version of the API this wrapper is for, hence splitting my versioning (the first part) from the API version (second part)
The middle part is not really needed, just thought about adding that to have a proper split instead of 1.1.0-6.5.0
I just feel like seeing 1.1.0-composable-v.6.5.0 makes it clear that this is lib version 1.1.0 meant for API 6.5.0 and if the api changes to 7.0.0 I can release 1.1.0-composable-v.7.0.0 which is clearer than just having 1.1.0.1
To give some more context, even tho people tend to hate it. These are blockchains, the code is often released ahead of time and the actual chain is updated later on and exposes a new version of the API from there on.
Hence build dates make very little sense
Also going from 1.1.0-composable-v.6.5.0 to 1.1.0-composable-v.7.0.0 implies no additions while sth like
1.1.0-composable-v.6.5.0 to 1.2.0-composable-v.6.5.0 doesthe presence of the
-blbalblab is exactly what defines whether the version is prerelease or not
this is how it is prescribed by the official SemVer website, and NuGet follows SemVer exactlyI see makes sense. I could use an underscore instead of a dash to get around it I guess 🤔
https://i.imgur.com/eUTRCI4.png
But that just sounds meh
Hate to break a spec like this
An autogenerated
nupkg has an autogenerated dependecy list which usually uses the >= operator for all it's dependencies. You don't need to release a new version of your library everytime a dependency gets an update, it's automatically the minimum version.Its not a C# dependency, basically just refers to a bunch of protos that this wrapper was generated with
So changing the 2nd part here is basically updating a bunch of git repos, extracting the protos and running a few source generator steps. No code changes tho
Why do you need
composeable in the Cosm.Net.Composable package and gaia in the Cosm.Net.Gaia package?Not needed, just looks nicer than
1.1.0-v.6.5.0
None of this is decided, I'm just trying to hear some opinions on what would be a reasonable thing to use as the basic semVer feels meh here
Oh well, underscores are not allowed at all 😆Imho, it's perfectly fine, when you utilize the
revision for your changes, like 1.0.0.65Just makes it very hard to spot to someone installing this if that package is up-to-date or not.
e.g. for gaia I could just go to their github repo, check that the latest release is v15.1.0 so I know that the package is compatible.
If its just 1.0.0.65 I'd need to go to the Cosm.Net repo and check which commit the submodule is checked out to
But given lack of a better option that might be the go-to solution hmm
1.1.0+andromeda.v0.1.0 would be syntactically validWell, just my opinion, but a quick and dirty solution would be to combine the repos version
15.1.0 to a single integer in your revision -> 1.1.0.1510 - i'm not sure on that one, but afaik every segment is a Uint16 which makes it represent up to 65535.Oh that could be a valid option as well
But now that I read the description for build metadata in the version (behind the +) I think that makes the most sense semantically as well
Thus two versions that differ only in the build metadata, have the same precedence
There is a testnet and a mainnet for each package so it could be useful to have both
1.1.0-gaia-v15.1.0 and 1.1.0-gaia-v15.0.0 around with no precendence as these are both the latest for their repective network
Sure I could add a new package Cosm.Net.GaiaTestnet instead but there's already 15 packages which take a total of like 10 minutes to build. Would prefer not having to double that
Will think about it, the simpler collapsed thing in the revision or maybe even build metadata isn't that bad of a solution either
Thanks for your time, appreciate it:halfsalute: