Stricter Release Management

[embano1]

The project is growing with more users and contributors. In order to ensure a good user experience, i.e. don't break installations due to out of sync master/release, we need to improve our release process.

I propose a Github dev/release process as described in the diagram below (details here):

Detailed writeup of the diagram above here.

The following changes to the repository structure/documentation are required:

• Create "development" branch - @embano1
• Update contributors guide with PR instructions - @embano1
• Create PR template for contributors - @embano1
• Automated appliance deployment - @lamw
• Automated regression tests (deploy appliance, test a set of function) - @lamw

Please provide feedback/missing action items so we can start with a more streamlined release process.

@lamw @vladi-velikov @martindekov

[lamw]

I'm currently updating all example README to reflect our discussion of checking out development branch as part of running through the examples. I noticed we don't have any consistency on the README as well, so we may want to create a template for that. You can assign that to me

[martindekov]

So we keep master stable. When we start developing we checkout master in develop branch. Every contribution(pull request) happens against that develop branch. Once we decide that it is time to cut a release the develop branch is merged into master and then new develop is checked out from master to continue development?

I just want to make sure I understood it correct. Otherwise it seems like a pretty good developing strategy 👍

[embano1]

@martindekov Yes, that's what I would like to suggest and thx for the feedback.
Just updated initial comment: created a development branch (also default branch now). We don't need a release branch as we would just tag the development branch for a certain release at a given commit and then merge into master (so master always reflects the latest stable release). Since development is the default branch we don't need to check out from master after tagging/merging a release into the master. Sounds good?

[embano1]

Some useful references for automating builds (especially go related) and creating changelogs:

govmomi: vmware/govmomi#1375
Changelog generator: https://github.com/git-chglog/git-chglog/
ir2proxy: https://github.com/projectcontour/ir2proxy

[embano1]

Closing this one as we will have unit/integration tests for the event router bits and automating the appliance build is too much effort for now.