-----BEGIN PGP SIGNED MESSAGE-----
Adam GROSZER wrote:
> Hello Tres,
> Thursday, April 29, 2010, 4:05:36 PM, you wrote:
> TS> Stephan Richter wrote:
>>> On Thursday 29 April 2010, Baiju M wrote:
>>>>> +1 to use a KGS. ZTK or BB depending on what the dependencies are.
>>>> Since normally we don't pin versions in trunk, I guess we need to
>>>> do the pinning in maintenance branches. Otherwise we can
>>>> keep the version pinning in trunk, but comment the "versions" option.
>>>> Then, just before going for release, uncomment it.
>>>> This will become one more step in creating releases:
>>> Why not leave it always pinned? This way the pinning gets transferred to
>>> branch/tag automatically.
> TS> - -1. Trunk development should not be hindered by the need to maintain a
> TS> KGS of some sort. Testing the trunk against a given KGS should be a
> TS> separate step from testing against "current" releases.
> You could "extends=" some sort of KGS, then override some versions
> It's just crazy that you buildout friday, test, all tests pass.
> You buildout monday, test, failures... because some versions moved.
If the develpoers who work on trunk don't live with that problem, how
can they expect "downstream" folks (e.g., "real" users or KGS
maintainers) to figure it out?
The workflow I am proposing is that when the nightly tests begin to
break due to a dependeny, the developer updates the setup.py (*NOT* the
buildout.cfg) to pin minimum or maximum versions of dependencies.
Later, the developer might relax or adjust those pins after tweaking the
package itself. Prior to release, the developer double-checks those pins.
Deferring the pain by testing only against a KGS just means that you
lose the information about which changes caused the breakage at the time
they happen. When the time comes to update the KGS itself, weeks or
months after the fact, the unfortunate KGS maintainer hs no idea what
changed or how to fix it.
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -