Make source-build sustainable about source-build HOT 5 CLOSED

From my point of view, part of this needs to be that the individual repos need to publicly announce which versions/commit-ids are the basis of the official/Microsoft-build.

@omajid I'm putting together the plan for the second phase of work that gets us to what you are describing (especially the 'annouce' part). This issue captures only the prelude to getting source-build and the constituent repos to mesh.
@wfurt @omajid I agree we need to support both scenarios of recreating latest stable and latest head.

from source-build.

We can produce community source builds with a clean checklist of steps to 'sync' with repos.

From my point of view, part of this needs to be that the individual repos need to publicly announce which versions/commit-ids are the basis of the official/Microsoft-build.

from source-build.

That depends on what you are trying to achieve @omajid If we trying to add ability to re-create official build than the official build can simply have manifest with versions used.
I could also see use for mode where you either use latest stable or simply latest head. Depending what you choose there will be implication for stability and capability of final cli. (or what ever we are building)

On a side note I also see different modes: one is full top-down build. that can be for example used by vendors and CM. However it would also be useful if developers can assemble cli using their private bits.

from source-build.

Fair enough. I guess part of this touches on branching strategy. As a developer, I would love to have master here track the latest development branches of all repos. And as a distributor, I would love to have individual branches tracking official .NET Core releases.

from source-build.

yes, that would be ideal. With that, I think the "version/hash" info needs to live in this repo.
Optionally, we could simply override it with with something like ./build.sh hash=master (or current or what ever tag)

Also many places I've seen this was solved in two stages: Getting correct code was done at checkout. And stage 2 simply build what you have. In our case it seems like the stage2 still has lot of code to check versions etc. When we want to build "stable" we can simply checkout from released branches. But I don't know if we tag/branch for maintenance releases. (we may still use commit hash as unique identifier)

from source-build.