Long pending changes of python version compatibilities
fmigneault opened this issue · 10 comments
Description
PR #520 seems to indicate that many fixes where made to resolve dropping Python 2 and errors during handling of mismatching dependencies across python versions.
As of yesterday, version 4.2.10 still does not include them. They are only 'pending' in master:
https://github.com/geopython/pywps/compare/master..4.2.10
Every tag since 4.2.4 are in parallel and diverging from master, without any backported fixes.
Since pip 21.0 enforces stronger dependency validations with their new resolver, it now becomes impossible to "cleanly" install pywps.
Either pathlib is missing and pywps complains, or it is installed and many other packages break due to overridden builtin pathlib.
A proper sync between master / release tags should be done once and for all.
Why are there even releases of features not integrated in master?
@cehbrecht How should this be handled?
@fmigneault sorry about the mess. We have merged several things to quickly to master (dropping py2 and proposed job queue). The new job queue implementation on master is not used and probably we want a different implementation.
To get out of this I would propose the following:
- make a pywps 4.4 branch for python 3 only
- we need to create this branch from master with the already python 3 only PRs (#520).
- we merge the PRs from 4.2 branch into 4.4 branch.
Maybe we can move the current master to a dev branch for the current job queue implementation.
The pywps 4.4 branch would then become the new master.
After that we need to think again about finding a solution for the job queue implementation.
I could do the following:
- create a new pywps-4.4 branch based on pywps-4.2
- backport (cherry-pick) patches from master (excluding new job queue)
- clean up: py3 only, test
- make a 4.4.0 release
Next:
- move current master to a dev branch
- make the pywps-4.4 branch the new master
@jachym @tomkralidis @huard Thoughts?
Sounds good !
+1
Maybe we can move the current master to a dev branch for the current job queue implementation.
The pywps 4.4 branch would then become the new master.
I like this idea. Experimental features should be in a separate branch and merged only when deemed appropriate.
The most confusing thing in this repo is that its landing page defaults to master which is not aligned with recent releases.
The plan sounds good.
I'm curious, why it jumps from pywps-4.2 to pywps-4.4 ?
I'm curious, why it jumps from pywps-4.2 to pywps-4.4 ?
In pywps the Linux version schema was used. Even 4.0, 4.2, 4.4 version numbers for stable releases and uneven 4.1, 4.3 for unstable releases. We have not really used this. We may give it up starting with version 5.0.
There is now a pywps-4.4 branch with integrated patches (#574) from master.
I can do the following:
- make a 4.4.0 release ... for testing that things still work
- if necessary make a 4.4.1 release with patches
"main" is the new "master" on github:
https://github.com/github/renaming
Using this I can create a new "main" branch based on pywps-4.4 ... "main" becomes the default branch. We can freeze master ... or rename it?
When we have a "main" branch we can start with version 4.6:
- re-format code with black
- ...
@cehbrecht Sounds good. We'll update our servers with 4.4.0 and report any issues we find in our staging tests.