New branching model

[tebjan]

how about adopting the 'develop' branching model and configure the master branch to automatically publish to nuget?

https://nvie.com/posts/a-successful-git-branching-model/

so all development and PR's will go to the develop branch and when things are release ready, a push to the master branch will trigger an appveyor build with automatic package publish to nuget.org.

[mrbean-bremen]

I guess that will make releasing easier - I'm not completely sure, though.
The current workflow (use the master as development branch, and make a release branch at release time) is more common, at least at GitHub, and we probably could adapt the release script to only generate a release for a release branch (sic), based on the branch name, for example.
Though in the end, both models are more or less equivalent, as far as I can see, so if you want to go that way, I have no problems with that.
Maybe someone else has some experience with that (@gvheertum ?).

[tebjan]

both is totally fine, we'll take the model most regular contributors feel comfortable with. so let's wait for some input from others.

[gvheertum]

I am in no way a git expert (even worse, sometimes I completely mess up in git 😊), but the downside to a master-release approach is that there is no easy way to update a release if a bug is found, if you branch to a release branch you can push updates to the release branch and are able to more easily test on these release branches.

Although you can label the master branch with release-versions, having a branch might simplify working with specific versions (especially if we are going to have multiple major versions (like we did with the non .NET core and the .NET core versions).

What I've seen is that develop is the "nightly/unstable" and on release (or after a sprint ending) the changes are pushed to master. Upon release a release-branch is made and the release is built from this branch. But I have to say that I only worked in teams that came from TFS, so possibly the TFS/Microsoft way of working kinda biased the approach.

[mrbean-bremen]

I'm also used to this model - a development branch (aka integration branch, aka master, aka trunk), and a release branch for each release and release patches. I have used this with svn, Mercurial and git, so it does not really depend on the tool.

[mrbean-bremen]

BTW: this has been called the cactus model - as a direct response to the aforementioned article. I remember having had a similar discussion before... Though the correct name is trunk based development.

[H1Gdev]

I think that git-flow is excellent, but it takes some time.

So, Github prefers a simpler Github-flow.
This is the model we are using now.