Refactor QA setup #610
Refactor QA setup #610
Conversation
|
Thanks @aleksihakli, but this needs a Python environment list still, check out the constance config: https://github.com/jazzband/django-constance/blob/master/.travis.yml |
|
@jezdez Python version list is now included in |
1 similar comment
|
I'm sorry, I wasn't clear about what I mean, tox-travis is best set up in using per-Python version test harnesses like in https://github.com/jazzband/django-constance/blob/b62206da573c1447b79ebc95a430df809672092d/.travis.yml#L3-L8. |
|
@jezdez I made an intermittent commit with the Python version listing as usual in Django projects and It also includes other 3rd party packages such as Pillow or Boto and the matrix configuration then becomes Thus the the test matrix definition is essentially the same size, but the Python variables will be introduced twice in the The problem is that there needs to be a way to specify the Django
10000
AND package versions along with the Python version with It would of course be possible to define multiple environment variables where one is e.g. I have previously configured simple matrices and am familiar with them and |
|
Just as a clarification: using the |
|
@jezdez I think the configuration is more to your liking now, figured out how to configure the matrix in a way that should fit this project and the requirements. Also added @camilonova the test bench should work now and only do one deployment per tag utilizing the Travis job stages. The setups should also auto-version now as long as the git tags are in place :) I think that it's best to explicitly exclude combinations with |
|
@jezdez @camilonova the work in this PR is now ready for review and possible upstreaming work-wise, I'm done with iterating over it. There are a lot of changes in this one PR and patch, but they all relate to CI, testing, and versioning. Splitting them up doesn't really simplify things, as it's easiest to see and review their correlation at once. All the changes aside from the The docs were also broken on Python 3 due to the use of |
|
@jezdez requested changes are implemented now. |
|
@aleksihakli Sorry, this needs another pass for the |
- Use setuptools_scm for deployment version number inference. - Only run deployment once after all tests have passed. - Skip deployment on existing packages on PyPI mirror. - Deprecate EOL Python versions from the codebase. - Utilize tox-travis and Travis test matrices. - Clean up test scripts and definitions. Fixes jazzband/help#182
|
@jezdez |
|
I forgot to say thanks for the work to @aleksihakli 🙏 - agree on @jezdez's reasoning to remove 3.4 and 3.5 support, just think it'd be best to separate, so that the previously tagged 0.12.6 patch release (adding Django 3.0 support) could be released without the backwards incompatible and non-warned parts. Maybe someone can upload 0.12.6 manually? I think the PR description could be upgraded so a patch release isn't let out that removes Python 3.4 and 3.5 support. Seems ideal for a 0.13 release, and perhaps most people would have their problems fixed if 0.13 could be immediately released from this PR? CC: @camilonova |
|
@benjaoming it's probably easier to just release 13.0.0 as that's most sane release scheme according to Semantic Versioning https://semver.org/? I think that 12.6.0 can just be skipped if it's not vital to release it? If it's not uploaded to PyPI then there's no harm done :) |
|
@Aleksandar-Todorovic there are probably thousands of projects dependent on sorl-thumbnail, a few of which might be reusable apps trying to introduce Django 3.0 support in a complicated/diverse set of Django and Python support and release cycles. Django 2.2 is still active, and so is Python 3.5. If sorl-thumbnail skips 0.12.6 and removes Python 3.4 and 3.5 support, then we either have to go and create nitty-gritty conditional dependencies in Since there were no changes in the code, and the PR description says
...I think the correct thing to do would be to reinstate Python 3.4 and 3.5 support in This could well be the final release in the 0.12 series before moving on to a 0.13 series w/o Py 3.4 and 3.5? |
For the record, the number of apps that refer to sorl-thumbnail as a dependency is 15 according to libraries.io.
|
|
@benjaoming if you want Python 3.4 and 3.5 supported please feel free to add them to the package identifiers and test matrix! I don't have much opinions on it other than Python 3.4 is officially EOL. Python 3.5 is also decreasing in usage and I have to say that the people who run old Python versions are rarely running the latest library or framework versions. However, adding back the identifiers is easy enough, please do so if you feel that is the best solution. I am not the maintainer, I just try to actively improve Jazzband QA automation and dream of deprecating Python versions prior to 3.6 due to feature parity :) |
|
Sounds good @aleksihakli , thanks for fixing all this! Sorry, I have been writing the wrong version numbers consistently in this thread! 12.7 would be a fine release according to semver for the dropped Python support. I think 12.6.1 would a be a correct bump for a release with these fixes, apart from the dropped Python support. I'll add a PR nominating master to move to a 12.6.1 release as a step before 12.7. |
|
@benjaoming roger that, although I'm not Aleksandar. |
|
haha, no, it was the first "aleks" auto-suggestion for |
|
@aleksihakli @jezdez love you folks ❤️ |
Fixes jazzband/help#182
Some notable changes: