release a new version ?

[12rambau]

You recently merged #2400 which is adding a super cool new ignoring mechanism. Would it be possible to make a release to make it available for CI/CD that cannot rely on git repository ?

[DimitriPapadopoulos]

We would need to add documentation for that new feature. Perhaps we can defer that after a release. Would you interested in a PR to add the documentation?

[12rambau]

I can have a look sure

[12rambau]

everything is living in the readme right ?

[DimitriPapadopoulos]

Yes, for now there's just the README.

[mdeweerd]

Updated features is not the only good reason to make a release: dictionnary updates are as well.
From the tag dates I notice that there can be quite a big time lapse between releases.
Could there at least be a regular release for dictionnary updates?
Perhaps the versioning could be appended with a '-' where number starts with one and is incremented for each dictionnary upgrade. There would not be any functionnal change for a dictionnary upgrade and they would only be release for the latest code version.

[LecrisUT]

Perhaps the versioning could be appended with a '-' where number starts with one and is incremented for each dictionnary upgrade.

I would recommend the opposite, and always have dictionary udpates on minor releases. The reasoning is that bug fixes should in general be compatible with the current version used and should not require more work to update. Dictionary updates can lead to quite a lot of work for the developers where they might not be ready to review.

I've seen similar workflow in cibuildwheel where the python versions and supported OS are changed at a minor release version, particularly since it's a GH action where there is a standard to move tags. Codespell does not have moving tags/branch and pre-commit does not support that, so it is not super relevant, but still having a standard for the release would be helpful for the users.

[mdeweerd]

Perhaps the versioning could be appended with a '-' where number starts with one and is incremented for each dictionnary upgrade.

I would recommend the opposite, and always have dictionary updates on minor releases.

I guess that my wording was wrong because that is an intended result of my proposal - the '-1', '-2', '-3' appended to a version increment with each dictionnary update, not for functional updates.

[12rambau]

but that's the point, changing the dictionary is a real change for users so at least a feature. I would avoid to reinvent the wheel in version naming convention to make sure that CI/CD pipeline continue to understand what is happening.

The dash will not be interpreted thus a "<1. 2" requirement will take into consideration "1.2.1-1" and "1.2.1-2" etc which is not a wanted behaviour from my side at least.

[LecrisUT]

I guess that my wording was wrong because that is an intended result of my proposal - the '-1', '-2', '-3' appended to a version increment with each dictionary update, not for functional updates.

Yes, and I am referring to that as well. Functionally -1 acts like how distros append their release patches on top of a X.Y.Z version. And unless the intention would be to cherry-pick this to every bug-fix version (which would be a nightmare to automate), the dictionary changes between bug fixes would not be picked up.

And functionally, the authors should not be getting CI failures for anything bellow bugfix changes, for which updating dictionary has a high probability of producing.

As I understand the intent of -X is to have more frequent dictionary updates, which I am in favor of, but it would be better for this to be opt-in and have a more well curated update on the minor release. You could also achieve a more frequent dictionary update if you have a dedicated branch for next-dictionary which rebases itself on top of the most recent version and just contains new dictionary, like a bleeding edge branch for those quick on their feet. This of course would be quite a drastic workflow change, with unknown benefits thus far. It would be better to simply push more frequent minor releases.

[mdeweerd]

The "-\d+" numbering scheme was mainly an example, it can be whatever fits desires.

Another solution would be to have a package for the dictionnary that would be a dependency similar to tomli, but a required one.

The pre-commit setup provided by codespell would specify a minimum version (last one known at release time).
The user can specify another dictionnary version in the additional_dependencies section of a pre-commit configuration.
The dictionnary could use a different versioning method more indicative of how old it is (e.g., v2024.4.3).

Dictionnaries are probably compatible across versions so one could just upgrade the dictionnary without upgrading codespell itself.

[LecrisUT]

This would also work. But it should be documented that pre-commit has caveats around additional_dependencies ¹, which could make updating it a bit tricky. Pre-commit does cache based on .pre-commit-config.yaml so you would have to pin the dependency version there and make sure dependabot, renovate etc. update the pinned additional_dependencies field as well.

Footnotes

1. https://github.com/pre-commit/pre-commit/issues/2758#issuecomment-2032471055 ↩

[edgarrmondragon]

Bump. I think this fell off yall's radar.

[DimitriPapadopoulos]

@larsoner I would like to see a new version before landing #3425.

[larsoner]

Just cut https://github.com/codespell-project/codespell/releases/tag/v2.3.0 / https://pypi.org/project/codespell/2.3.0/

[jamesbraza]