v3.4.0 - release

[fearphage]

@DABH @wbt I pushed a tag to v3.4.0

Planning to push this to NPM when I get a chance. Last thing after that is to promote the tag to a release.

Thoughts? Concerns?

[wbt]

Thanks for the note!
I did a release on winston-transport earlier today (incl. publishing to npm), landing some other long-awaited patch-level changes. If I got anything wrong there, I hope someone corrects me soon, but it seemed to go pretty well.

Based on the diff, I was thinking it'd be a patch-level release but after @DABH merged in Seq transport, bumping the feature version seems more appropriate. I was hoping for a little additional clarity on #1952 and #1973 before doing a release, but those were my only remaining to-do items.

Don't forget to update package.json and package-lock.json before creating the release tag, so the tag has the versions with those numbers. (You might need to go to 3.4.1 now for a distinction.)

[wbt]

Oh - and don't forget to update the changelog before the version tag too.

[fearphage]

I removed the tag to do more planning. I changed the version to 3.4.x to draw a distinct line in the sand more than for semver reasons.

[DABH]

I agree with doing a 3.4 release. I think enough has been merged already that a release is warranted. We'll probably want to do at least one more release in the near future as we burn through the remaining PRs (or, e.g., if we update logform or winston-transport and need to get that newer version into winston). Thanks for taking the lead on this!

[rcollette]

You might want to look at dropping the diagnostics package. It has not been updated in three years and has transient dependencies with vulnerabilities.

3rd-Eden/diagnostics#24

With all the scrutiny on Log4J, this type of issue is going to be a hot topic in teams for all loggers.

[wbt]

Issue for tracking that last post is #1995; thanks!

[DABH]

Folks, due to the compromised versions of colors, I went ahead and released Winston 3.3.4. Sorry to jump the gun but I figured getting something out would cause is less headache than waiting to do a bigger release…

[wbt]

@DABH Thanks for the quick response.
At this point in the aftermath of that, what exactly was released? There is no release tag for 3.3.4 enabling an easy comparison. Did you go back to the 3.3.3 release, update the dependency, and release that as 3.3.4 (similar to this suggestion) or was it just publishing master to npm (current diff here)?

If it's the latter case, we probably should be calling it 3.4.0 to better respect semantic versioning.
I see your appropriate warning in the changelog, but now that we've gotten past that we should discuss what really happened and get it right.

[wbt]

We should probably also add a 3.3.4 tag on just what was released, so we have that for reference.

[DABH]

@wbt Apologies the release tooling didn’t make a GH release. Master at HEAD is 3.3.4 (“fix npm audit vulnerabilities”). I’m happy to release a 3.4.0 (and create a GH release properly — will use np instead of vbump I think) with better release notes etc. But really the most help I need is figuring out why this test started failing even on older commits, I’m banging my head against a wall and don’t have enough time to keep investigating today. I do have enough time to make a new release if we can stabilize the tests…

[DABH]

Oh if there’s not even a 3.3.4 tag I’ll fix that, the tooling definitely indicated a tag was made :/

[wbt]

OK, I retract my prior statement about semver - having looked through the diff to master, it looks like a patch-level release. I was distracted into thinking it should be a feature-level release by the introduction of the Seq transport but that's actually just a documentation change referencing an externally maintained library, rather than an addition of functionality here. Hence #2012.

[wbt]

Looking at the project history, I see the following timeline from yesterday, times in EST:
5:03 PM: issue fixed with merge of #2008, tests passing.
8:54 PM: 'v3.3.4' commit directly to master. This commit updates the changelog with a semver warning, updates the version number of Winston in package.json, drops two inactive maintainers from the list, and updates the minimum patch version of logform and winston-transport. package-lock.json is updated. Tests start failing.
8:54 PM: The tag '3.3.4' is created, lacking a v at the start of the tag like others have. No Github release is created from this tag.
9:13 PM: In another direct-to-master commit "fix all high-severity vulnerabilities from npm audit", the major version of mocha and the feature versions of three @babel packages as well as async are updated, though only the first should really make a difference because the others use a caret range.
9:35 PM assuming I did timezone conversion right: winston is published on npm.
Next day 11:51 AM: I merge #2012 with improved release notes.
Going on npm and clicking 'try with RunKit' to browse the files as currently published to npm, looking specifically at package.json, it looks like the 9:13 PM commit made it into the publish, but not the tag, so the tag lacking the v is misplaced by one commit. I will remove that and add the v two commits after where it was, to include the updated release notes, and make a Github release from that.

[DABH]

Sounds good, thank you for helping sort this out. There are always issues with getting things back running smoothly after such a long time with no releases, but hopefully we (I) will be able to avoid these issues with subsequent releases.

[wbt]

Note that it's not possible to overwrite the published package on NPM with the updated release notes. However, we're probably not too far from a 3.3.5.

[DABH]

Yeah. I think due to #2006 we'll probably want the next release to be 3.4.0 just in case. But anyway, we can do another release pretty soon, e.g. as soon as we figure out why tests are not stable.

[wbt]

I agree that a feature update number would be appropriate after the #2006 merge.

[wbt]

It looks like there's one more unhandled rejection listener than the test expects, and that's why it's failing. The other one is added first (index 0) - I wonder if there was an update in how the test runner handles uncaught rejections or something like that?

Interestingly, the 3-year-old commit containing the failing test says near the top

// This is an awful and fragile hack that
// needs to be changed ASAP.
// mochajs/mocha#1985

The referenced issue is twice that age and still open.

[DABH]

Uh oh 🙃 If this is just an issue with mocha, maybe the right move is to do something like relax our test to loop over all unhandled rejection listeners and see if any of them has the desired properties? Fixing mocha is probably more than what we signed up for :)

[wbt]

Released per comment by @DABH here.
If there's more to include, another release can be done, but I've been all day on this and need to return to other work.

[DABH]

Thanks again @wbt , hopefully this keeps Winston happy for quite some time :) Cheers!!