devlooped
💟 Adopting SponsorLink in v3.5
In order to improve the long-term sustainability of this (and other) projects, we'll be adopting SponsorLink v2.
Please get familiar with it, read the privacy statement and raise any doubts related to it in the SponsorLink repo itself.
All of SponsorLink is OSS too.
What this means for you:
- If you're not a sponsor (or you haven't synchronized your sponsorship), you will get a IDE-only warning reminding you that the project needs sponsorship.
- CLI or CI builds will never check for sponsorship.
- Sponsorship status for GitInfo/ThisAssembly is no longer optional for in-IDE usage (to compile warnings-free, exclusively in the IDE).
- If you're an oss author (thanks for being one of the 35.8k authors contributing to 2.4k repositories producing 4.7k packages with 22.2M combined daily downloads), will never need to sponsor me to use my stuff, unless you want to 💜). Just sync your status with
dotnet tool install -g dotnet-sponsor; sponsor sync devloopdand enjoy!
Can you eventually explain "that the project needs sponsorship."? Just to get rid of the warning or does it realy need an active sponsorship to be legaly used? And how does that work out for projects using TreatWarningsAsErrors? Does this mean the project must be sponsored to get rid or otherwise the library has to be removed to get the code to compile at all?
Sponsorship status for GitInfo/ThisAssembly is no longer optional for in-IDE usage.
As noted, SponsorLink applies only to IDE usage. The requirement is not legal (it's still OSS). You can keep using it if you just ignore the warnings.
But it wont be possible to use <TreatWarningsAsErrors> as the generated code will cause CS0618 warnings due to emit due to the usage of [Obsolete]? So its either:
- sponsor
- disable TreatWarningsAsErrors
- ignore CS0618
Or one is now locked out of building. And if the conduct fobids to disable point 2 and 3, its basicaly sponsor or remove the dependency if you want to keep being able to build in your IDE?
That's correct. And since sponsorships can be company-wide in addition to individual (or you are implicitly a sponsor if you contributed to an active nuget package that's OSS), this should be a very low bar for continued usage/adoption.
You can of course remain on an older version too.
Okay, understood! Well, for me personally and my team at work this means we will replace GitInfo with an alternative. While the idea behind this is noble and a good thing, this enforcement of a warning and the acceptance of an issue this produces is the wrong approach from our point of view. But thanks for the quick response!
@IceReaper did you find a alternative? We are in the same situation.
@IceReaper did you find a alternative? We are in the same situation.
We use GitVersion as an alternative. A very good alternative!
@AndreasBieber do you have a link, the following does not seem to be maintained https://www.nuget.org/packages/GitVersion and does it have the source generated git information?
Using GitVersionInformation.ShortSha or GitVersionInformation.Sha from
https://www.nuget.org/packages/GitVersion.MsBuild
is a good "fix" to avoid the IDE warning. Thanks for the hint.
I couldn't get GitVersion.MsBuild to work, but Verlite worked like a charm, It sadly doesn't have the commit date but I can live without it.