On 12/29/18 2:52 PM, Thomas De Schampheleire wrote:
El sáb., 29 dic. 2018 a las 0:58, Mads Kiilerich
(<m...@kiilerich.com>) escribió:
# HG changeset patch
# User Thomas De Schampheleire <thomas.de_schamphele...@nokia.com>
# Date 1546030612 -3600
# Fri Dec 28 21:56:52 2018 +0100
# Node ID 43b3bbf90a48adfcfb4837655cffee3a939bf48f
# Parent 445d6875c2eefdd8d10676e761cfe1e82581f78a
setup.py: allow Paste 3.0.x
My main concern for whitelisting new major versions of dependencies is whether
they are sufficiently backwards compatible. We should try to mitigate that with
some amount of testing and review, and preferably a brief mentioning of it in
the commit message.
What can be said about this upgrade?
Paste has a new maintainer and moved to github, after years of
inactivity (March 2016 -> Oct 2018). There have AFAICS not been
incompatible changes.
Thanks.
Note that we also *could* upgrade and support:
celery==4.2.1
Markdown==3.0.1
Pygments==2.3.1
pytest==4.0.2
pytest-localserver==0.5.0
Routes==2.4.1
Sphinx==1.8.3
- but I know that some of these break things and are non-trivial ...
I generally think that we should try to stay more or less up-to-date
with the versions of external components. Staying on old versions will
cause problems at some point.
But, this desire should be weighed against time/effort factors.
Sure. If the upgrade really is easy and low risk, then it is easy to do.
From
the list above, I think celery could be more important to investigate
than the others.
I think they changed the API. Or we just use it in an odd way. If
upgrading, we should perhaps drop support for < 4.
(One specific issue I have, but probably related to how we call
celery, rather than a problem inside celery itself, is that if the
smtp server responds with "Try again later" then the message is not
queued and thus lost).
Ouch.
(Also, "celery" is just an implementation detail. And a quite complex
and fragile one - especially if using rabbitmq. But at our scale, it
would probably be better to just use a sql database. And most
immportant: Our commands and documentation should perhaps just talk
about "worker process".)
Do you have more details about which of these upgrades you know break things?
I think Routes also changed alot.
Ideally, our test suite would catch any such breakage: if the tests
pass, the upgrade should be fine. If that is not the case, then we
need to improve our test suite.
Yes. If we assess that an area has good test coverage, then a safe
upgrade is easy.
/Mads
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
