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 > [email protected] > https://lists.sfconservancy.org/mailman/listinfo/kallithea-general _______________________________________________ kallithea-general mailing list [email protected] https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
