Development process changes

[darrelmiller]

Moving forward, I don't think we should continue with the vnext branch. We ended up accumulating too many changes in the vnext branch and for every reported bug fix we had to deal with the question of should we merge the fix into master or into the vnext branch.

There are bunch of recently opened bugs that I would like to get fixed and I wanted to get them into the 1.1 release, but it was continuing to delay the release and we already have people using the -preview Nuget in prod.

If we have a feature that merits a minor release, then we should just release it. Accumulating these changes to keep the version numbers low is of dubious merit.

On a related note, I would like to change the way we create release notes to use a markdown file in the repo. The file should be updated as fixes and features are completed, rather than having to update the GitHub page. We can still create GitHub releases and tags, but do it automatically from the VSTS release process.

Thoughts? @PerthCharern @Shwetap05 @xuzhg @scott-lin @EricAtMSFT

[Shwetap05]

@darrelmiller make sense, then there is no more preview of any features that are added to the library? e.g. i wanted Diff to be released as preview and if there is no VNext how do you suggest we release it? As a major version of library?

[PerthCharern]

• Based on Process for managing patch releases vs minor releases #260, shouldn't every bug fix go into both the master and the vNext branch? If we make the bug fix go into vNext branch every time it's merged into master, then the vNext will always have the most updated patch as well. You should not have to deal with "the question of should we merge the fix into master or into the vnext branch."

• This would still allow speedy release of the minor version. The reason why we had to split it out was to allow an even speedier release of the patch when the minor version was under going "preview" release.

• Could you elaborate on the release note a bit? Are you suggesting we maintain a new markdown file? I am okay with any process as long as it's easy to figure out what has been released in each version.

[darrelmiller]

@Shwetap05 We manually update the nuget package for each release. There's no reason why we couldn't add a -preview tag in the master branch for a preview release.
There is an interesting variant described here where master always deployes a preview and you branch to a rel/1.0 rel/1.1 when you choose to cut a release. One nice thing about that is that you don't need to create a dummy PR that needs to be approved just to remove the nuget -preview.

@PerthCharern Yeah, bug fixes should go in both releases. I guess I just got into a bad habit of fixing the a bug in the vNext branch which is a mistake. I think I had never relalized that we don't need to split the bug fixing from the updating the patch number and we can release the patch immediately with the bug fix. No preview required.

Regarding release notes, yes I'm suggesting a .md file that has headings for each release and a list of the items addressed in that release. For the preview releases, we probably shouldn't make a distinction between releases.

[PerthCharern]

@Shwetap05 @darrelmiller

I'll add bug-fix and feature-work labels. I think we should apply these to future PRs, so that it'clear what's being done. It will allow reviewers to help verify which branch the work is to be merged into.