Marked: Versioning

[DanielHabenicht]

What pain point are you perceiving?
"I am using renovate to update my packages (with auto merging enabled) and a marked update got auto merged because of a minor release, which broke things in production. "
That will be somebody (maybe me) in the future.

I now that you heavily discussed releasing a 1.0 and this should be a little reminder that not having released one still is an issue for all users of the package.

Describe the solution you'd like
What I propose is releasing a 1.0 version as soon as you can and going from thereon.
A version number says nothing about the matureness of a project (and this has been around for long enough that it is definitely mature enough for being released) its sole purpose is to make it clear to the user what has changed. (e.g. a major release beeing a breaking change).
If you have some things in the pipe that will trigger a major release in the future - so be it. Please refrain beeing connected to the aesthetics of the version number and use it for its main purpose. (Sry, if this is a little bit harsh. I really like this package and I know that much of your free time has been detecated towards this project. But this is bugging me. )

In order to make it easier, you might want to check out semantic-release which automates the whole process of determining a version number, writing changelogs and releasing a new package version based on the commits. If you have any questions on how to do it or need support setting it up mention me.

[UziTech]

The plan is to release v1.0 once all CommonMark and GFM specs are passing.

Right now we follow semver for 0.x.y where x is breaking changes and y is non-breaking changes.

If you want to help get to v1.0 we have many spec issues that could use a PR 😁

[DanielHabenicht]

I will have a look at those issues in the advent season. Too much to do at the moment.
How do you like semantic-release?

[UziTech]

I use semantic-release for many of my own projects but I don't think it would be helpful before we release v1.0. I feel like it would be better for this project to have many fixes in each release instead of releasing on every fix.

With so many dependencies (73.2K according to libraries.io) there would be (and already is) a lot of them that would be struggling to keep their package up to date if we were releasing any faster.

[DanielHabenicht]

Yep, definitely after v1.0.
The pace of releases can be set by running the release task only once a week or working on a pre-release branch which can be merged to master if a release should be created.

I don't quite get your second paragraph. If you withhold updates from them they won't get the changes either. And when somebody is updating they will always get the current state nonetheless how often we release?
I am also against noise like releasing 4 times a day, this would be quite annoying to people using renovate or else.

[calculuschild]

I just ran into this myself. Dependabot tried to auto deploy for me and it broke all of the styling on our documents.

[DanielHabenicht]

@UziTech which of the spec Issues referenced above do you recommend for a beginner in this project?

[UziTech]

@DanielHabenicht you can do whichever one you want. I would just pick one and try to work on it.

[UziTech]

The easiest way to get marked up to spec would be to look in /test/specs/commonmark/commonmark.0.29.json, find a spec with "shouldfail": true and set it to false, then try to get the tests to pass.

[DanielHabenicht]

Mhm, I am sorry but I will also change to markdown-it. Just for versioning purposes, it is not likely that I implement all 100ish test cases. Keep up the good work, this is still the fastest markdown parser around.

[UziTech]

Markdown-it is a good library that is very extensible. The markedjs team has been talking about releasing v1.0 sooner since the move to spec compliance has been slower than originally planned. We will release a new plan soon and I think we should be able to release v1.0 in the next couple months.