search

shurcooL / github_flavored_markdown

GitHub Flavored Markdown renderer with fenced code block highlighting, clickable header anchor links.
MIT License
160 stars 43 forks source link

Add release #13

Open schollz opened 7 years ago

schollz commented 7 years ago

Thanks @shurcooL for the great library! I was reading #12 because I was also having problems with dep. I managed to just modify my Gopkg.toml to use version 1.5 of blackfriday instead of 2.0. I was wondering, could you make a release of github_flavored_markdown so I can lock in the current version? This will help me stay locked in to what currently works, in case you plan on upgrading github_flavored_markdown to follow the new blackfriday v2.0.0.

dmitshur commented 7 years ago

I need to think about this before I can commit to using tags (and maintaining them for years to come). I currently only support the latest version of all my packages, see my SLA for more details.

I was wondering, could you make a release of github_flavored_markdown so I can lock in the current version? This will help me stay locked in to what currently works, in case you plan on upgrading github_flavored_markdown to follow the new blackfriday v2.0.0.

The problem of blackfriday v1 vs v2 is independent of normal versioning as it's supposed to work. They're supposed to have different import paths, but there's a bug/unintended behavior where the wrong package is being used at a given import path. It's being discussed and tracked in #12 (and parent issues).

I don't plan on upgrading github_flavored_markdown to use blackfriday v2 soon, but if I did, I would be sure the latest version of the package and its dependencies continues to work.

spekary commented 3 years ago

I would like to echo the request to tag a release. It makes it much easier to depend on your project using a go.mod file.

By tagging a release, you are not committing to anything. It just makes it so that people can recreate builds using the tag, rather than a commit tag, which is much uglier.