Closed lmilbaum closed 1 year ago
I second this.
https://github.com/markdownlint/markdownlint/pull/452 has also been merged earlier today and it would be great to have it included in a new tag.
Are you asking for a tag in GitHub or a release to RubyGems?
Are you asking for a tag in GitHub or a release to RubyGems?
The Arch package I maintain is based on the latest GitHub tag's commit and my personal lint CI is based on the latest RubyGems release so, ideally, both I guess... :angel: :smiley:
You can reference GitHub commits and branches the same as tags, so maybe that helps with your first scenario.
While I could technically do that, our packaging guidelines imply that we should base our packages' versions and sources against the latest quoted "stable" tag/release made by upstream. Referencing a "random" commit that does not correspond to any particular tag on GitHub side in the package this way isn't an option regarding our packaging standards. Hence why I seconded this request to create a new tag I can base the package on.
Although, if creating a new GitHub tag is a concern for any reason or isn't a plan right now that's okay! I was just seconding the initial request but I can wait if needed :)
I don't speak for this project, it just seems to me that people are asking them to tag every commit and that doesn't seem to provide much value over referencing the commit directly.
What about releasing a new version? I'm waiting for a new version to get new features.
@mathroule For testing purpose, I followed the «Alternatively you can build it from source:» of the project's landing page, which provides the most recent functionality of the principal branch.
In an instance of Linux Debian 13/trixie (the otherwise ruby-mdl
package for this OS I use intentionally removed) and elevated sudo privileges, the request
git clone https://github.com/markdownlint/markdownlint
cd markdownlint
rake install
yields mdl
. Contrasting to the packaged ruby-mdl
, there is the additional entry about SARIF added recently:
$ mdl --help
Usage: mdl [options] [FILE.md|DIR ...]
-c, --config FILE The configuration file to use
-g, --git-recurse Only process files known to git when given a directory
-i, --[no-]ignore-front-matter Ignore YAML front matter
-j, --json JSON output
-l, --list-rules Don't process any files, just list enabled rules
-r, --rules RULE1,RULE2 Only process these rules
-u, --rulesets RULESET1,RULESET2 Specify additional ruleset files to load
-S, --sarif SARIF output
-a, --[no-]show-aliases Show rule alias instead of rule ID when viewing rules
-w, --[no-]warnings Show kramdown warnings
-d, --skip-default-ruleset Don't load the default markdownlint ruleset
-s, --style STYLE Load the given style
-t, --tags TAG1,TAG2 Only process rules with these tags
-v, --[no-]verbose Increase verbosity
-h, --help Show this message
-V, --version Show version
Can this bypass be temporarily useful for you?
Thanks @nbehrnd. But I'm using Markdown lint as a dependency of another Ruby project and on CI. So I'm more interested in an official release version (even if there are workarounds to use it from a branch or a specific commit).
D'acc, this is different from deployment as standalone linter from the CLI.
@jaymzh could you please help releasing a new version of Markdown lint?
I will release a new release when I have some time.
Thanks!
version 0.13.0 released
Description
The MD033 allowed elements was pushed after the last tag. My projects uses pinned versions. With that, a new tag would help me pulling in the required change.
P.S. You might want to enable Discussions. It is useful for such a request.
Environment
MDL Version
Expected Behavior
Actual Behavior
Replication Case