Considering incremental releases

[jjvanzon]

• Related: A build / solution just for code coverage? #9

Background

The 15 public NuGet packages have not be completely unit tested. Currently the plan might be to unit test all 15 public NuGet packages before releasing all 15 at the same time. The idea behind releasing them all at the same time, might be that it might be hard to guarantee stability between an older higher dependency and a deeper newer dependency.

But is taking quite some to get to that point, also due to diminished capacity to do things.
It is like running up a high hill, instead of incremental releases. It may contribute to how heavy this feels.

Idea

Releasing incrementally, one component at a time, might have some advantages.

Might there be a way to do stable intermediate releases of newer JJ.Framework components without releasing all the packages at once?

Maybe JJ.Framework.Common (a deeper dependency) could be released. Perhaps by testing it with older other components (upward the dependency). With the newer unit tests?

Perhaps a branch with a solution that uses unit tests as csproj, but referencing NuGet packages from nuget.org except the newer code of the component I would like to release. I might never merge that branch, with this specific specialized solution.

Would it even need an never-to-merge branch? Could it just be a different solution for this release. Hmmm... perhaps also with different unit test csproj, which may look messy and more difficult to maintain.

It could be a set of solution and project files specifically for incrementally testing and releasing the components.

It remains to be seen how this might work out in practice.