Re: [Zope-dev] ZTK compatibility testing
On Fri, Mar 5, 2010 at 8:56 AM, Christian Theune wrote: ... > 2b: ensuring ongoing compatibility of the trunks > > In addition I wonder how the various trunk versions of ZTK packages > should relate to each other. Should they always build? Should we accept > breakage of all trunks with each other or not? > > Also, there is not version of the ZTK (I think) that specifies 'use the > trunk of everything', right? IMO, there should rarely, if ever, be changes on the trunk that aren't in the most recent known good ZTK distribution. The way I've done this is: - Check out the ZTK - Check out a working copy of the package(s) of interest and build as develop eggs with the rest of the ZTK. - Hack till I'm happy and the ZTK tests pass. - Check in changes to the packages and make new releases. - Update the ZTK buildout to use the new releases and test again. - Test with multiple Python versions. - Check in changes to a branch of the ZTK. - Run tests of the branch on windows. If they pass, merge the ZTK branch to trunk. With buildbouts, ideally there'd be a stage branch we could merge to, wait for the buildbots to to their thing and then merge to trunk when tests pass on all platforms. I really think we want to avoid long-lasting unreleased trunk changes to or long-lasting newer releases not in the KGS for ZTK packages. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZTK compatibility testing
Hi, as promised I'm currently trying to write down the instructions for running ZTK tests. I need some feedback on our process. I figured there are various scenarios for which we have tools: 1. Ensure that a branch of the ZTK stays in working order For that the ZTK has test runners created by z3c.recipe.compattest which ensures that the individual tests of the ZTK packages with their respective dependencies using the specific ZTK versions are ok. This helps when evolving the versions in the ZTK. Those should be run nightly as is done by some of the buildbots. 2. Ensure that a change of a package doesn't break the set 2a: ensuring compatibility with a specific branch of the set The developer working on package X can use a compat test runner and a specific ZTK buildout configuration to run the other packages' tests combined with the development version of package X. This can/should be done by individual developers for the (newest/olders?) ZTK version they target their change for. If we can encode the "target ZTK" version for a specific package in that packages' configuration then we can also have nightly builds that perform this verification automatically. I'm not sure how to encode that, though, because the relation between the package and the ZTK is usually defined the other way around. 2b: ensuring ongoing compatibility of the trunks In addition I wonder how the various trunk versions of ZTK packages should relate to each other. Should they always build? Should we accept breakage of all trunks with each other or not? Also, there is not version of the ZTK (I think) that specifies 'use the trunk of everything', right? Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
