TL;DR since 1.0.0 LiGet will be a fork of BaGet. Read lower why...
We have previously created and used LiGet from various pojects, just to get it working on dotnet core.
When BaGet started to look promissing, we contributed some work there with indention to migrate from LiGet to BaGet and obsolete the project.
However, following was deal-breaker:
What we consider critical basis for mature project was not merged:
build must be reproducible, which in current .Net world means paket.lock commited in source repository.
released product must be built CD-style. Which in short means to build artifacts only once, and run them through a pipeline of tests and QA. It is not acceptable to run dotnet build or dotnet publish several times for same commit. There must be a well-defined set of binaries which were tested through all pipeline stages.
if docker is released then docker image must be tested with end-case tests running actual nuget clients.
long feedback time for PRs in BaGet. I spend only a few days at time to get job done. I cannot wait weeks for review.
How is this fork different from upstream BaGet:
using FAKE for build system, rather than scripting in MsBuild.
added unit, integration tests and e2e tests with paket and nuget cli.
TL;DR since
1.0.0
LiGet will be a fork of BaGet. Read lower why...We have previously created and used LiGet from various pojects, just to get it working on dotnet core. When BaGet started to look promissing, we contributed some work there with indention to migrate from LiGet to BaGet and obsolete the project. However, following was deal-breaker:
paket.lock
commited in source repository.dotnet build
ordotnet publish
several times for same commit. There must be a well-defined set of binaries which were tested through all pipeline stages.How is this fork different from upstream BaGet:
/api/cache/v3/index.json
than private packages/api/v3/index.json
Notes
<1.0.0
and all e2e tests are passing.