Open phatcher opened 4 years ago
For reference, this is part of/in response to #713 and #654
Ah, i suggest keeping things simple.
Then
release/xx branches for having versions that we also deploy. Github can IIRC be set up to handle those properly. Easy to open a branch and then merge this branch back into master to give gitversion a version to work from.
preview/xx as preview branches. I would assume we may want to have something where we can dump versions into (from master) to get feedback while also maintaining a trace
This gives an archive of which version was released and should allow gitversion to do it's work. I do not really see us patching older versions, or?
Nuget:
release/ and preview/
get pushed to nuget. Nightly do not, we keep them separate (on azure) and publish the necessary nuget configuration so people can use them. This allows one to use either the nightly version, or the released or previewed versions easily with very little config work.
Azure should be public- we get a lot of licensing if it is public (10 agents iirc). And we can use it to run the unit tests there.
Looking forward to see how you set this up - I am fighting on this full automation at the moment.
Great initiative, guys!
I've set up the org/project, will work on a pipeline this weekend - https://dev.azure.com/simpleodataclient/Simple.OData.Client
As per @NetTecture suggestions, I'm going to create a Simple.OData.Client Azure organisation with associated build pipeline and an associated artifacts repository which would allow us to produce nightly builds and/or builds from feature branches. We can then decide which of these should be pushed to nuget e.g. betas might be but nightly builds/features branches might not.
I also propose that we adopt SemVer going forward via GitVersion, this will make managing package versioning much more intentional and make it easier to support feature/beta versions of the package.
So the open questions are...
Comments/thoughts?