Put an upper bound on bleach and comment each and every dependency

[benjaoming]

Maybe it's useful to start commenting on why a dependency is there and what expectations we have for the versions that are pinned? What do you think @oscarmcm ? :)

Fixes #1252

[codecov]

Codecov Report

Merging #1253 (247f2e4) into main (0e2a10d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1253   +/-   ##
=======================================
  Coverage   79.19%   79.19%           
=======================================
  Files         109      109           
  Lines        4657     4657           
  Branches      531      531           
=======================================
  Hits         3688     3688           
  Misses        761      761           
  Partials      208      208           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[oscarmcm]

LGTM 🥇

And thank you for the comments in the dependencies 💯!

[oscarmcm]

Shouldn't we also pin the Pillow version?

[benjaoming]

Could be good, I don't have strong opinions on this one... I don't even know what the lower bound should be.

[oscarmcm]

I'll leave this one as it is, bcz most projects already have/use a pinned Pillow version and Django-Wiki will use that version (if its in the right order).

[oscarmcm]

Maybe we can someday drop sorl-thubnail and use easy thumbnails? or provide a better integration in order to avoid template tag name collision.

[benjaoming]

I don't know TBH.

sorl-thumbnail has been quite stable. Not a lot of bugs, but maybe it's good to switch to a project that is actively developed.

[oscarmcm]

@benjaoming Quick question, do we need to draft a new release after this? I believe this is a breaking change and prevents the app to be used.

Will wait for your answer in order to merge it.

[benjaoming]

Yes, this should be a new release. But IIRC, we already made changes in main that should bump the minor version :)

[oscarmcm]

Yeah, I believe this should be the workflow we can follow now:

• hatch version - Should match the current release version (0.9)
• hatch build
• hatch version minor - If I'm not wrong should be 0.9.1
• Create a new release tag
• Push the new release tag
• hatch publish
• Add the artifacts to the release tag

[benjaoming]

hatch version minor - If I'm not wrong should be 0.9.1

Ah no, that would be a patch version. We should bump to 0.10. This doesn't mean that we'd want to support a 0.9.x series with patch updates, but more to cater for people who expect 0.9.x to not break... because we might break stuff with the series of changes going in here: https://github.com/django-wiki/django-wiki/pulls?q=is%3Apr+is%3Aclosed

I did also kind of skip writing change logs 😇 https://github.com/django-wiki/django-wiki/blob/main/docs/release_notes.rst

[oscarmcm]

Ah oks, that sounds great! can't wait for this release!!

[statsconchris]

Using pip install --pre wiki doesn't take this update into account. I keep getting the error. --pre doesn't read the main branch?

[oscarmcm]

Hi @statsconchris I've replied in the discussion #1257 (comment) maybe that option works for now until we release a new version.