Release 0.5.1

[joshbruce]

Publisher

• $ npm version has been run.
• Release notes in draft GitHub release are up to date
• Release notes include which flavors and versions of Markdown are supported by this release
• Committer checklist is complete.
• Merge PR.
• Publish GitHub release using master with correct version number.
• $ npm publish has been run.
• Create draft GitHub release to prepare next release.

Note: If merges to master occur after submitting this PR and before running $ npm pubish you should be able to

1. pull from upstream/master (git pull upstream master) into the branch holding this version,
2. run $ npm run build to regenerate the min file, and
3. commit and push the updated changes.

Committer

In most cases, this should be someone different than the publisher.

• Version in package.json has been updated (see PUBLISHING.md).
• The marked.min.js has been updated; or,
• release does not change library.
• CI is green (no forced merge required).

[joshbruce]

We should reconsider this in the checklist for releases. I really like the evolution of the release notes so far, really helps me know what type of version number to use. But, I don't know how much value the markdown flavor will have - nobody has really requested it since whoever it was made me think it would be a good idea...or I'm blind at it is there (been rough).

"Release notes include which flavors and versions of Markdown are supported by this release"

[UziTech]

Shouldn't this be 0.5.1 I don't think there were any breaking changes or new features added since the last release.

[styfle]

@UziTech This is where it gets tricky with semver. The output changed in several cases so I think that's not considered "backwards-compatible bug fixes".

Here are the release notes if you can't see them:

Release notes

Security

• Fix inline code regex and prevent REDOS fix inline code regex #1337
• Use @markedjs/html-differ to previous dependency REDOS use @markedjs/html-differ #1331

Major

• Fix typographic substitution in (pre|code|kbd|script) blocks when smartypants=true Fix typographic substitution in (pre|code|kbd|script) blocks when smartypants=true #1335
• Fix auto-linking email Fix auto-linking email #1338

Patch

• Refactor the escape() function to improve performance 10-20% Refactor the escape() function to improve performance 10-20% #975
• Update copyright in source code Update copyright in source code #1326
• Update benchmark tests bench against commonmark instead of showdown #1019

That being said, it seems like nearly every bug fix is backwards-incompatible. So maybe I mislabled the major ones and they should be patches? I think these bugs were introduced in 0.5.0 so it would make sense to release 0.5.1 with the fixes.

[joshbruce]

@UziTech: That's possible now that I think about. Think the zero major threw me.

@styfle: Also here.

Versioning

We follow semantic versioning where the following sequence is true [major].[minor].[patch]; therefore, consider the following implications of the release you are preparing:

1. Major: There is at least one change not deemed backward compatible.
2. Minor: There is at least one new feature added to the release.
3. Patch: No breaking changes, no new features.

What to expect while Marked is a zero-major (0.x.y):

1. The major will remain at zero; thereby, alerting consumers to the potentially volatile nature of the package.
2. The minor will tend to be more analagous to a major release.
3. The patch will tend to be more analagous to a minor release or a collection of bug fixes (patches).

Think @UziTech is correct. I was think we were using the minor for both breaking and non-breaking changes. Forgot what the docs say (now I have that song stuck in my head).

[joshbruce]

The Major heading means we would be doing a major release, if we weren't on the zero-major, yeah (good UX, btw)? So, it would be 0.6.0. If everything was under Minor then it would be 0.5.1, yeah?

[styfle]

I'm fine with this release being 0.5.1

[UziTech]

I guess every fix could break someones workflow 🤣

[styfle]

@joshbruce I updated the release notes to use the name 0.5.1 instead. Would you like to fix this branch or make a new one?

[styfle]

Should be 0.5.1

[joshbruce]

@styfle:

Tempted just to ship it as 0.6.0 - lazy, but feeling much better. lol

Probably keep the same branch, the only thing running nom version doesn't really do much: https://docs.npmjs.com/cli/version - we can delete after the merge.

Probably keep the same PR as well, change the name.

In the future, here's how my brain is working, just to make sure:

• If there's anything under the major heading in the release notes, gonna do a minor while under the zero-major.
• If there's anything under the minot or patch heading, gonna do a patch while under the zero-major.

This one's free to be weird, we'll get it sorted. 😂

[joshbruce]

ps. Still think the major, minor, patch idea was pretty brilliant. Having said that, probably helped us more than the users.

[styfle]

lazy, but feeling much better. lol

@joshbruce Glad you're feeling better. If you want to take it easy and give publish permission to UziTech or myself, then we can step in when you are unavailable to avoid blocking releases.

[joshbruce]

@styfle: Thanks for asking. Will put together a couple of PRs using the template per the process of changing things. :)

Or you and @UziTech could do it as well.

Now that things seem relatively stable with the crew I don't have concerns around it like I did before.

[joshbruce]

Ah, never mind...didn't notice that in the authors page changes. We've kinda lost the roadmap to people to contact for what, which was one of the first things brought up by @davisjam before he became part of the team. @styfle you okay letting me trying some stuff? I will do my best to incorporate both of our concepts; or, we can straight up collab on it.

[styfle]

I think we should collaborate in the private org/team chat of GitHub to make sure everyone on our team can participate in this change.

[joshbruce]

@styfle: Just to make sure I'm following and making clear the idea and current process.

1. Authors page: Would like to make modifications re the HTML and layout of "the cards".

2. Making people owners on the package: We have a process in place for publicly requesting or recommending changing someone's status in the project via PRs (this way it's transparent to the community - I'm big on transparency Federico to committer #1150). See badges template (edit: the badge y'all would be getting is the Release Wrangler, which automatically makes you a publisher of the package...as it stands, outside the conversation, I'm only needed for the add to the package because I'm the only one who can do it outside of @chjj.)

Which (or both) are you thinking should be handled in the org chat?

[UziTech]

marked could also be moved under the @markedjs org on npm

[joshbruce]

@UziTech: I don't have an issue with that. Think we talked about doing that before and decided against an org in NPM. Not saying things can't change, just can't remember why we had decided not to - make sure we're not forgetting a dealbreaker.

[styfle]

marked could also be moved under the @markedjs org on npm

As far as I know, moving to an org would force all dependents to change their package.json to reference the new package. I don't believe there is such a thing as aliasing packages and I don't think it would be a good idea to publish to two packages. Instead, we could publish to the org and deprecate the old.

That might make more sense for v1.0.0 along with splitting out the CLI (which would be a breaking change).

• @markedjs/marked
• @markedjs/cli
• @markedjs/html-differ

[UziTech]

Moving to an org doesn't mean the package would need to be namespaced. I have almost all of my npm packages in the UziTech org but none of them are namespaced.

I believe the packages can only be namespaced if they are part of an org though.

I do think the community is moving toward namespacing packages so they are harder to impersonate.

I agree this would be a good thing to do in v1.0.0 or maybe v2.0.0 when we remove most options and make them their own extentions

[styfle]

Well that's new to me! I like it, let's do that! 👍