0.17.0 Release Plan

This issue will be used to track any overarching discussion and work related to 0.17.0.

Scope

As always, everything discussed in this issue is subject to sudden change at my sole discretion. No promises or hard commitments 😃

All related issues will be tagged with the 0.17.0 Milestone.

Here’s a few things additional I’ve been thinking about (most don’t have an associated issue as of now), but not guaranteed any of these will make it in 0.17.0.

• Don’t have both requirements.txt and dependencies in setup.py, deduplicate
• User-defined OutputFormatter classes to allow users to specify the format of the output. Would allow us to easily implement #45 and #53.
  • OutputFormatter classes would just be found in the --extra-path
• GitContext.config(name, default=None, use_cache=True) method for easy access to git config (that is also cached). Optionally also provide a mechanism for easy fallback. E.g. default can be a string and/or a lambda that implements more complex logic like returning from environment config.
• New Rule: ConfigRule: git config commands
  • This can just be implemented as a commit rule that just runs a _git command (or GitContext.config - see above) to pull the value and then compare it to a given regex. By using named rules, users can implement multiple of such rules.
• Respect git config core.editor for commit msg editing instead of only falling back to vim if $EDITOR isn’t set
• gitlint github action
• Attempt to fix coveralls.io integration with Github Actions (see .github/workflows/checks.yml#L60-L66)
• Windows: work a bit on fixing existing issues
• Move to Poetry for packaging/building?
• Remove dependency on sh in integration tests
• Unit Tests: fix running on Windows, try again 😃
• Equality checks need some review, especially wrt class checks. Check all __eq__ and __ne__ methods, same for str and repr methods

Timeline

As always, no specific timeline, but probably in the new year (2022).

[jorisroovers]

Ok, TIL, thanks for educating me 😃

If the best-practice for macports and homebrew is to not pin the dependencies, then I think it makes sense to follow 😃

As a general note: Re-iterating that we’re not committing to officially support these packages, i.e. if a gitlint distro package breaks because of dependency issues, we’ll look at it if and when we want to, not necessarily with priority. That’s just to be able to keep the limited time we have focussed on maintaining gitlint itself.

Thanks for all your help @harens, makes a difference!

[jorisroovers]

@harens so I’d like to avoid having gitlint aliased to gitlint-core, since that will bypass the default trusted dependencies setup we introduced which was the whole point of this change. The default method should still be to install gitlint and then pull in gitlint-core[trusted-deps] automatically as a dependency during installation. Really not different from how other dependencies are resolved.

Does that make sense?