Add doc that explains public VS. Stable releases

[AArnott]

No description provided.

[MarcoRossignoli]

@AArnott out of scope...I did't take a look at code but you can answer quickly...to count height do you check every update of version.json file and compare schemas querying repo history?

[MarcoRossignoli]

So could be possible have a master always in -beta and when someone wants release remove beta, do commit generate package and relese and right after re-add -beta to start a "new pahase"?

[AArnott]

possible, yes, but tedious. It doesn't leave you a branch for servicing that release either.
For this (and I'll add this to the doc), we offer the nbgv prepare-release command.

[MarcoRossignoli]

Great clear.

[MarcoRossignoli]

@AArnott many compliments...ngbv lib+commands are a bomb for versioning lib...I'try to apply "all concepts" step by step with @tonerdo

[AArnott]

@MarcoRossignoli To count height, I walk history by commit from HEAD to the last commit that retains the same version property integers. So changing major.minor or major.minor.patch will reset the height, but adding or removing a -beta will not reset height.
Then there's logic to deal with branches with multiple ways to get to the last commit. This I believe is documented in the README.

[MarcoRossignoli]

This I believe is documented in the README.

Yes I wonder only how it's implemented, you walk commit history for version.json file...maybe there was some other trick or you booked ver in some git metadata place, but it's not so.

[AArnott]

Version height calculation starts here.

[MarcoRossignoli]

Thank's!

[MarcoRossignoli]

@AArnott in a case like our where we have 3 components with different version for historical reason we should update version.json like

release.branchName = "release_msbuild/v{version}"
release.branchName = "release_collector/v{version}"
release.branchName = "release_console/v{version}"

and run nbgv prepare-release inside project folder, right?

[AArnott]

@MarcoRossignoli ugh. I don't know how well that will work or if there's a better way. I've never heard of quite your situation before when using prepare-release. I suppose you could try it and see.
But if you plan to release all at the same time as a rule, personally I might try for maintaining just one branch for each release instead of 3. That might mean that prepare-release isn't useful.
On the other hand if you might release just one package for servicing, then one branch per package might make sense.

[MarcoRossignoli]

On the other hand if you might release just one package for servicing, then one branch per package might make sense.

Eh at the moment is our use case, because the "core" is shared between 3 "drivers" but not all support all code feature(passing parameters) and "drivers" doesn't provide same "added features", but this is a "design" issue to me, maybe in future we will be able to "merge features" in core and let "drivers" to be only "pluggable entry points".

I agree...if we'll decide to "align" version some day maybe will be better.

BTW I did some tests on my custom repo, tool and the idea works very well.