dependency restrictions question

[ng0]

On 17-02-19 22:15:05, Mads Kiilerich wrote:
> 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.

That's a good idea, though I think I won't easily find support for that
in our system. The preference is to use stable upstream releases unless
they fix something system specific.
Do you have an guestimated date/range of a new release? Otherwise I'll
look into the dev branch and see if I can make some use of it.
 
> /Mads
> _______________________________________________
> kallithea-general mailing list
> kallithea-general at sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general