Plone 4.1 is more than 2 years old and keeping compatibility with it becomes harder and harder.
I think we must just move on drop support for it.
if it makes our life a lot easier i'm fine with it. if it's just about some additional zcml-conditions i'm not.
what is the problem you're currently working on that could be solved more easily without supporting plone4.1?
Allow failures under Plone 4.1 (refs. #36)
main problem is Dexterity: version pinning is hard to maintain under CI and that's why I have dropped support for 4.1 on all our packages that depend on it.
i see - testing infrastructure with travis is on my to-learn list :-)
could http://good-py.appspot.com/ help here?
does allow_failures mean: if tests fail for plone4.1 just ignore them?
is there an easy way to mark tests for dexterity somehow so they're not run on plone versions <= 4.1?
yes, it's pretty easy; just check http://docs.python.org/2/library/unittest.html#skipping-tests-and-expected-failures
on the other side, yes KGS help but maintaining a clean CI configuration with that is PITA; if you really want to test under Plone 4.1 I'll create a special travis.cfg for it, but only if you really want to keep compatibility.
so if maintaining the test infrastructure for plone4.1 is a lot of work and/or PITA we can skip that imho.
this does not necessarily mean, that we don't care about BBB in the code though.
what do you think @petschki @joka ?
👍 for dropping 4.1 support
http://good-py.appspot.com/release/dexterity/1.2.1?plone=4.1.6 should give you the right versions for Dexterity on Plone 4.1.
@davisagli I think is more important to bring support for plone.app.contenttypes than to maintain support for Plone 4.1.
dropping support to Plone 4.1 will make it easier to add support to plone.app.contenttypes.
Drop support for Plone 4.1 (closes #36)