Le 21/10/2013 14:02, Héctor Velarde a écrit : > On 20-10-2013 16:50, Encolpe Degoute wrote: >> Sorry for the delay: I'am against. >> It's not a good idea to make plone tests on an external resource. > > HV> reverted; let me explain a little bit more what I want to do and why: > > keeping compatibility with previous versions of Plone is now easier > using Travis CI, but when it comes to Dexterity-based content types we > have to do some uggly stuff to include the right pinning. > > I just made a comparison and these are the only differences on version > pinning between a vanilla Plone 4.1 installation and one that includes > Dexterity 1.2.1: > > +collective.z3cform.datagridfield = 0.10 > -collective.z3cform.datetimewidget = 1.0.5 > +collective.z3cform.datetimewidget = 1.1.1 > +five.grok = 1.2.0 > +five.intid = 1.0.2 > +grokcore.annotation = 1.1 > +grokcore.component = 1.9 > +grokcore.formlib = 1.4 > +grokcore.security = 1.2 > +grokcore.site = 1.1 > +grokcore.view = 1.13.5 > +grokcore.viewlet = 1.3 > +martian = 0.11.2 > +mocker = 1.1 > +plone.alterego = 1.0 > +plone.app.dexterity = 1.2.1 > +plone.app.intid = 1.0 > +plone.app.lockingbehavior = 1.0.1 > +plone.app.referenceablebehavior = 0.3 > +plone.app.relationfield = 1.1 > +plone.app.stagingbehavior = 0.1b3 > +plone.app.textfield = 1.1 > +plone.app.versioningbehavior = 1.1 > +plone.behavior = 1.0.1 > +plone.dexterity = 1.1.2 > +plone.directives.dexterity = 1.0.2 > +plone.directives.form = 1.0 > +plone.formwidget.autocomplete = 1.2.3 > +plone.formwidget.contenttree = 1.0.5 > +plone.formwidget.namedfile = 1.0.2 > +plone.mocktestcase = 1.0b3 > +plone.namedfile = 1.0.6 > +plone.schemaeditor = 1.2.0 > +plone.synchronize = 1.0.1 > +rwproperty = 1.0 > +uuid = 1.30 > +z3c.blobfile = 0.1.5 > -z3c.formwidget.query = 0.5 > +z3c.formwidget.query = 0.8 > +z3c.objpath = 1.0 > +z3c.relationfield = 0.6.1 > +zc.relation = 1.0 > > this is what is being done in Plone 4.2 versions.cfg file as you can > see here: > > http://dist.plone.org/release/4.2-latest/versions.cfg > > I was thinking that probably my change was a bad idea because some > people could be using buildout.plonetest for deploying production > sites, something that seems to me an even worst idea :-) > > so, as I want to use this only for CI, this change could probably be > made on the travis-4.1.x.cfg config and not on the plone-4.1.x.cfg one. > > what would be the best way of doing this?
When I do such things I create a 'dexterity.cfg' with the data you showed above to fix the KGS and add it in a travis-4.1.X.cfg. The order is important: extend = plone-4.1.x.cfg dexterity.cfg > > comments? Usually, when a piece of the core has a separare roadmap (dexteriry, diazo, chameleon, …) I always use a separate file to fix the KGS until the Plone Unified Installer integrate it. Best regards -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
