Document release process

[SorraTheOrc]

We need to document the process for releasing from this repo into the Azure Quickstarts repo. Here's an initial set of ideas:

We aim to release every 2nd and 4th Wednesday

Version numbering

Version numbers are x.m.i, where x = major version number, m = month number, i = iteration number (e.g. 1.1.2 is the version from the 4th Wednesday of the month). If interim releases are needed (e.g. security patch) they will be indicated with an addition digit, e.g. x.m.i.y, where y is an incremental number

Release Preparation (1st and 3rd Wednesday)

1. validate all issues with milestone of next release. Move out issues that are going to slip.
2. Merge dev branch into releasecandidate branch
3. Increment version numbers in dev branch
4. test and validate releasecandidate branch

Release Process (2nd and 4th Wednesday)

4. Update URLs for deploy button and script locations
5. Update version numbers
6. cp code to azure/quickstarts fork
7. issue pull request
8. validate against best practice
9. merge into quickstarts

[SorraTheOrc]

@hosungsmsft can you please review this proposal

[hosungsmsft]

Given the long deployment time of the template, I'm not sure how the validations will work effectively and if the release period is a bit too frequent in that sense? Let's sync up offline on the validation methods.

[SorraTheOrc]

I'd much rather we do things that affect all users in the public space than offline (that's not to say we can't discuss offline and bring proposals here). The goal is to have the maximum input from potential partners. For example, my answer below provides an ideal opportunity for others to help us out...

The goal of fast release cycles is:

1. move as fast as users need us to
2. forcing function to automate as much as possible

I agree that long deployment times make manual testing difficult, the answer is therefore to set up a CI solution that is continually testing dev and releasecandidate branches (by the way, this is something I'm already working on ;-)