0.17.0 Release Plan

[jorisroovers]

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 Custom note to explain title-match-regex rule. #45 and Change formatting #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]

0.17.0 ended up being a small release, only tackling #162 and doing a few dependency bumps. Moving other planned items to 0.18.0.

@harens, can you work your usual magic to update macOS packages? Appreciate it!

Please note that with 0.17.0, gitlint is actually split into 2 PyPi packages: gitlint and gitlint-core. gitlint is still the main package, but it now depends on gitlint-core.

[harens]

As always, thanks @jorisroovers for pushing another release. Your work is greatly appreciated. ⭐

Updating the MacPorts portfile was fairly straightforward: macports/macports-ports@597742c. This involved installing gitlint-core under the name gitlint.

However, I'm unsure how to replicate this fix in Homebrew: Homebrew/homebrew-core#90087. Hopefully, one of the maintainers has some advice on how to do this.

[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?

[harens]

@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?

Thanks @jorisroovers. That completely makes sense, and is honestly quite a clever change.

Just so you're aware, MacPorts and other system package managers (AUR, nix, etc.) normally use whatever version is already present in the package manager. e.g. py-sh is currently version 1.14.2 in MacPorts, so this version would be used for gitlint. Pinning deps at the system level can lead to various breakages for end-users.

See the nix reddit and discourse for more information about this. MacPorts outright doesn't support pinning dependencies within portfiles due to the issues that arise.

Homebrew is a bit different in that it retrieves the dependencies directly from PyPi. If we wanted to, we could pin the version numbers, but two potential problems come to mind:

1. Homebrew's auto updating tool bumps dependencies to the latest version and generates their checksums. Pinning the deps means that the formula would have to be updated by hand.
2. Even if we did pin the deps, the tests would still fail since it's gitlint-core that installs the CLT rather than gitlint. Homebrew can't find the CLT in gitlint, and so errors out.

The simplest solution to these issues is to alias gitlint to gitlint-core, although I understand that this defeats the purpose of the change. Maybe the Homebrew maintainers can think of something better that strikes a happy medium :)

[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!