dependency restrictions question

[Mads Kiilerich]

On 02/18/2017 09:05 PM, ng0 wrote:
> Hi,
>
> packaging kallithea for Guix now moved to the QA phase and I have
> further questions about it.
>
> You have some strict dependencies on old or very old versions:
>   - mercurial 3.7.3
>   - dulwhich 0.9.9
>   - routes 1.13
>   - urlobject 2.3.4
>   - docutils 0.11
>   - markdown 2.2.1
>   - babel 1.3
>   - pyparsing 1.5.0
>
> and at least one old version dependency which results from these old
> package versions.
>
> We like to keep the number of our old version in-tree packages
> at a reasonable number, so my question is wether all of this is really
> necessary or if someone has tested new versions of the packages
> succesfully[0] and you just impose these restrictions because of
> unspecified reasons.
> If there are reasons, can you list them, if possible for every package I
> named so that I can add the reason(s) as code-comment to the packages.


(The "official" "supported" versions can be found in setup.py . You can 
patch it, and you can easily try different combinations if you test 
using a virtualenv and pip as suggested in our documentation.)

We try to make a good compromise between optimism and realism in the 
versions we claim to "support". Most of the constraints are "this is 
what we have reviewed, tested, and used in production and know works". 
There might be later versions - but we did and do know know the status 
yet. Some of the constraints can probably be lifted, especially if we 
assume "semantic versioning" ... but we really should check the release 
notes of the dependencies we update and test it thoroughly before 
claiming we "support" it.

Some version dependencies have recently been lifted on the development 
branch. If you are creating a new package, perhaps consider starting out 
packing the development branch and contribute fixes. Once the 
development branch is released as stable, you can switch to stable.

/Mads