Future release blog post improvements

[phillipj]

Just before node v4 got released, a script (scripts/release-post.js) for automatically creating release blog post (locale/en/blog/release/v4.0.0.md) was created in #88, atleast a first draft of it.

I would like to create a list of tasks to further improve that script, but it requires feedback about the current state of it.

• Fetch changelog from tag instead of master
• Add CLI argument to specify version (w/fallback to https://nodejs.org/dist/index.json)
• Leave pleaceholder for shasums if they're not found in /dist/
• Check to see if all of the binaries are available before putting links to them
• Remove ## header from changelog
• Add Author: <full name> in blog header, see #186 comment for hints

Most importantly: was it useful at all while releasing v4 @rvagg? If not, what has to change?

Current flow

There were some assumptions made about how the latest version number should be resolved, what changelog too use etc.

a) Fetch latest version from https://nodejs.org/dist/index.json
    |
    v
b) Fetch changelog from node's master branch, find changelog for latest version
    |
    v
c) Fetch shasums for latest version from https://nodejs.org/dist/
    |
    v
d) Render blog post with Handlebars template ./scripts/release.hbs
    |
    v
c) Write content to file ./locale/en/blog/release/v<VERSION>.md

Changelog

One thing I got curious about while observing the release, was which changelog should be used. It didnt look the v4's changelog got merged into master at the time of creating the release blog post, therefore the changelog retrieval would probably fail due to version mismatch.

What would be best approach? (1) from the release proposal v4.0.0 or (2) v4.x tagged changelog?

Any other thoughts?

[Fishrock123]

cc @nodejs/release

[rvagg]

For v4.0.0 I did the reverse and generated the post before the release, perhaps it's a special case because I did a writeup in there as well and maybe it'll be useful to generate this after the release is cut.

We edit the changelog on the stable branch we're releasing for and then cherry-pick that back to master, I'd like to see this be a normal part of the release procedure so we should be able to assume that master has an updated changelog but for safety I think fetching it from the tag of the release would be better, e.g.: https://github.com/nodejs/node/blob/v4.0.0/CHANGELOG.md - that way you don't need to know what branch we're on (v4.x in this case), you just use the existing information you have about the version number.

[phillipj]

Thanks! Will change it to fetch changelog from the tag instead.

Is it safe to assume that https://nodejs.org/dist/index.json will contain the latest version or should it be provided as a command line argument instead?

[rvagg]

that file is updated as soon as the person releasing has run the release commands

[phillipj]

that file is updated as soon as the person releasing has run the release commands

Alright... Added the ability to specify version with an argument aswell, just in case you or someone else wants to create the post before the version has been released again.

Created a PR to fix what has come up so far, although I'm all ears about more improvements.

[Fishrock123]

@phillipj ok so... I want to add a little blog bit to the changelog this week too, if possible. Do I just run this before the release? Do the binaries have to be in /dist/ first? ....?

[phillipj]

@Fishrock123 yes, adding content by hand is absolutely possible. The last step (c) in the flow results in a file being created ./locale/en/blog/release/v<VERSION>.md which you can modify as you wish before commiting / pushing. It's not added or pushed automatically, so no worries.

Do the binaries have to be in /dist/ first?

No, the binaries themselfs are not verified. Although the list of shasums is fetched from https://nodejs.org/dist/v<VERSION>/SHASUMS256.txt.asc, if it doesnt exist the entire script will fail.

I could easily avoid that crash and leave a placeholder for you to insert shasums manually instead?

[phillipj]

Just pushed a fix with a placeholder instead of crashing due to invalid shasums, making it easier to create these posts before releasing a new version.

Did the script provide any value to you while releasing v4.1.0 @Fishrock123?

[Fishrock123]

It was too late by the time the builds were done so @rvagg did the blog part.

On Sep 17, 2015, at 8:35 AM, Phillip Johnsen [email protected] wrote:

Just pushed a fix with a placeholder instead of crashing due to invalid shasums, making it easier to create these posts before releasing a new version.

Did the script provide any value to you while releasing v4.1.0 @Fishrock123?

—
Reply to this email directly or view it on GitHub.

[phillipj]

Alright. I'll merge the changes I've done so far in #164 to be ready for future releases.

[rvagg]

here's an improvement I'd like @phillipj, I'd code this up myself if I had time, perhaps I will if nobody else gets to it by the time I get frustrated enough to do it: check to see if all of the binaries are available before putting links to them. This could either be done by doing a HEAD request to their respective URLs or even just parsing the SHASUMS256.txt contents. Where they don't exist on the server replace their links with "Coming soon". This should normally only apply to ARMv6 builds but has been common enough when doing io.js builds that it's been standard practice to not wait for them before promoting the release.

[phillipj]

Sure thing @rvagg!

So to avoid confusion; all the files will be listed in SHASUMS256.txt, but they might not be available on /dist/ yet?

And how should this affect the list of files when you are running the script before the release, meaning SHASUMS256.txt wont exist either?

[rvagg]

SHASUMS256.txt will reflect what's in /dist/, it's taken directly from that directory so it'll always be accurate.

re doing this before a release, I'm not really sure how best to handle that because it's such a different workflow. How about for now we optimise for the run-after-release case and adapt later if it gets in the way.

[phillipj]

I have fixed binary verification locally now. Waiting for #157 / #172 getting merged before opening a PR to avoid a merge conflict mess.

[mikeal]

Where does the author field come from? I thought the release notes were automated?

[phillipj]

It will be automated soon, I'm working on it.

On Thursday, 8 October 2015, Mikeal Rogers [email protected] wrote:

Where does the author field come from? I thought the release notes were
automated?

—
Reply to this email directly or view it on GitHub
#156 (comment)
.

[phillipj]

Closing this issue for now as all tasks has been completed and merged. Open separate issues for further improvements.