Show the release notes in the product instead of providing link

[joaomoreno]

In order to get this to work we need to:

• Cleanup the release-notes folder and standardise the release notes markdown files names. Each file should be in a well defined format (e.g. v1.4.md would be a good format, since we only do release notes for minor releases, not patches) such that Code can locate them. @gregvanl
• Fix whatever breakage that renaming cause, namely the website, which already expects certain file names. @gregvanl
• Implement the rendering of the markdown inside Code itself. @joaomoreno

[joaomoreno]

@waderyan @gregvanl @bgashler1 Who can help me with the first two checkboxes in this item?

[waderyan]

We are meeting in a couple minutes for our website iteration meeting and we'll divvy it up.

[waderyan]

@joaomoreno - @gregvanl will pick this up. I added his name next to each checkbox.

[gregvanl]

@joaomoreno - I think we only need to change the filename format for new release notes (August 2016 and beyond) since earlier releases of VS Code won't support this change (the in product release notes fwlink still points to Updates root). I'll go ahead and rename vscode-docs vnext branch August_2016.md to v1_5.md. I'd like to go with using an underscore between the major and minor version.

[joaomoreno]

Excellent, thanks @gregvanl!

Btw is there any reason why we still have the vnext branch? Is there any point in time in which we work on the vnext branch and still work on the master branch? Couldn't we simply work directly on the master branch?

[gregvanl]

@joaomoreno vnext is where we write prerelease content that we don't want to go live until the release is out. For example, release notes and updating the main docs for new features coming at the end of a milestone. The master branch is were we write content reflecting the current stable release and we can publish at any time. At each release, we merge vnext into master and then publish that releases new content. It is very common for the feature team to be working in vnext during the end game while I or a PM might be adding or modifying a topic and publishing out of master.

[joaomoreno]

It would make more sense to switch those two concepts, similarly to what is done in most projects: keep master pointing to the latest and simply advance a website branch which will trigger a synchronisation to the website with the additional optional commits on top, much like we have master and release branches in Code itself.

It's OK though, I will simply fetch the release notes contents from master.

[joaomoreno]

Actually now that I think about this... I'm not sure we should be making requests to fetch the release notes Markdown files directly from GitHub. We might get throttled.

Any chance we can host the markdown files directly on our website so Code would fetch from it?

cc @waderyan

Postponing to September

[gregvanl]

Why don't we pull down the release notes .md file from GitHub during the build and include the markdown in the product install? That way offline users can still read the release notes and we don't have the complication of a web call.
The only time we'd update the notes post release would be a recovery build which would pull down the updated Markdown file.

[joaomoreno]

Are we always done with the release notes at the time of the build?

My fear is one day we'll forget about this and release something with unfinished release notes.

[gregvanl]

The past few releases we've been done with the release notes several days before the final build which happens after some days of Insiders bake time. I don't think enforcing a head deadline would be a burden since the dev team has usually moved on to working on the next milestone by the time we release.

[joaomoreno]

Makes sense... although I'd still prefer an online version.