Having worked on and released new versions of a few ZTK packages recently, I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as there doesn't seem to be an agreed process about this and in an attempt not to step on anyone's toes, I'd like to ask first whether it is OK for any developer to modify the versions listed in ztk.cfg (provided that all relevant tests are passing, of course). I'd currently like to update the following packages: zope.app.apidoc = 3.6.7 zope.app.publication = 3.9.0 zope.error = 3.7.0 zope.location = 3.7.0 zope.site = 3.7.0 zope.traversing = 3.8.0 -- Thomas
Thomas Lotze wrote:
Having worked on and released new versions of a few ZTK packages recently, I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as there doesn't seem to be an agreed process about this and in an attempt not to step on anyone's toes, I'd like to ask first whether it is OK for any developer to modify the versions listed in ztk.cfg (provided that all relevant tests are passing, of course). I'd currently like to update the following packages:
zope.app.apidoc = 3.6.7 zope.app.publication = 3.9.0 zope.error = 3.7.0 zope.location = 3.7.0 zope.site = 3.7.0 zope.traversing = 3.8.0
Thanks for bringing this up. There's indeed currently no agreed-upon process. Jim a while ago was proposing a rather heavy staging process where the trunk can only be changed if a staged branch passed all tests on all platforms (and Python versions) as run by a buildbot. We don't have the infrastructure for this yet and Christian Theune and I were wondering whether this is needed. An alternative process would be to only *release* the ZTK after the compat tests run on all platforms as shown by the buildbot. We do have infrastructure for that. So I'd propose the following development process: * developers can change the version numbers in the ZTK * if the compattests all run, they can check in And then for releases: * we determine we want to make a release of the ZTK * if the buildbot reports it all works on all platforms * we verify there have been no further modifications since then * we can release * what does a release look like exactly? We should at least have a documentation release sitting somewhere on docs.zope.org, with the release number in the URL. The 'current' URL should also point to this documentation. Along with this we should also publish the lists of versions for reuse. How? Regards, Martijn
Martijn Faassen wrote:
So I'd propose the following development process:
* developers can change the version numbers in the ZTK
* if the compattests all run, they can check in
I'll go ahead and update the KGS with my proposed new versions then; if someone experiences a problem with this, feel free to flame me ;o)
* what does a release look like exactly? We should at least have a documentation release sitting somewhere on docs.zope.org, with the release number in the URL. The 'current' URL should also point to this documentation. Along with this we should also publish the lists of versions for reuse. How?
I see two options: - make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a versioned URL - release a ztk egg that depends on the exactly versioned packages The latter is probably the more reusable. -- Thomas
On Mon, Oct 5, 2009 at 4:44 PM, Thomas Lotze <tl@gocept.com> wrote:
I see two options:
- make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a versioned URL
- release a ztk egg that depends on the exactly versioned packages
The latter is probably the more reusable.
I'd suggest to follow the Zope2 approach and provide both an index and a versions.cfg at a permanent place. The result looks like this: http://download.zope.org/Zope2/index/2.12.0/ You can use this with both easy_install and buildout easily. Andreas wrote a very simple script that is able to produce such a minimal listing. I don't see how a ZTK meta-egg would be of any value. Given that the number of packages included in the ZTK will change quite a bit over time, it doesn't make sense to depend on a ZTK egg for a package, as it doesn't provide any real stable contract. An egg with hard coded exact version numbers is pretty painful as well, as you cannot override those requirements to go for selected newer versions of any packages pinned in such a way. Opting for a newer zope.testing release for example is quite a common requirement. I don't think it makes sense for anyone to "install the entire ZTK". Projects being built on top of the ZTK are most often only interested in a part of the ZTK and will depend on such packages explicitly. What is valuable for those, is the stability contract between various versions of packages in the ZTK. Hanno
Hey, Hanno Schlichting wrote: [snip]
I don't see how a ZTK meta-egg would be of any value. Given that the number of packages included in the ZTK will change quite a bit over time, it doesn't make sense to depend on a ZTK egg for a package, as it doesn't provide any real stable contract. An egg with hard coded exact version numbers is pretty painful as well, as you cannot override those requirements to go for selected newer versions of any packages pinned in such a way. Opting for a newer zope.testing release for example is quite a common requirement.
I don't think it makes sense for anyone to "install the entire ZTK". Projects being built on top of the ZTK are most often only interested in a part of the ZTK and will depend on such packages explicitly. What is valuable for those, is the stability contract between various versions of packages in the ZTK.
I agree with this - I see little value in a ZTK egg, and I also agree the ZTK explicitly supports using part of the ZTK only. Regards, Martijn
Thomas Lotze wrote: [snip]
- make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a versioned URL
I agree we should make it available under a versioned URL somehow. Whether ztk.cfg can be reused directly or whether we should extract something in it with just the version indicators I'm not sure about. I've noticed when modifying the buildout.cfg of the ZTK to add z3c.recipe.depgraph support that I had to pin down *everything* that was pulled in by depgraph as well if I wanted to avoid getting buildout errors (some weird version conflict was taking place). I hope that ztk.cfg isn't triggering that. The reason I mentioned docs.zope.org as the release location is because we will also publish release-specific ZTK documentation when we make a release. The release-specific documentation should be maintained and tagged along with the ZTK itself, and we should have easy access to previous versions of the docs on versioned URLs. But it's true "docs.zope.org" isn't a very pretty URL for this. Perhaps we should have: http://ztk.zope.org/ This will contain the general intro about the ZTK and the version-independent management information we currently host at http://docs.zope.org/zopetoolkit/ There is also a release overview page, and this gives a list of the ZTK releases. There's also a link to the 'current' release: http://ztk.zope.org/release/current/ which in turn redirects to (or *is*?) the most recent version of the ZTK, for instance: http://ztk.zope.org/release/1.0 The release contains release-specific documentation, including a package list like this: http://docs.zope.org/zopetoolkit/releases/packages-trunk.html It also can contain the dependency graphs for that release, and any other release-specific documentations. (overview of changelogs for all packages?) Finally, and most importantly, it publishes the ztk.cfg for the release. As Hanno suggested, we can also host an index there. The structure might look like: http://ztk.zope.org/release/1.0/ztk.cfg and for the index: http;//ztk.zope.org/release/1.0/index/ I think it makes sense to separate the two and not have the ztk.cfg inside the index. You typically use either the index or the ztk.cfg file independently from each other, I think. As a side discussion: I'm not entirely sure what benefit the index is to the Zope 2 project however; doesn't using a custom index like this stop the project from using any other release on PyPI? I know that Zope 3 has a special index that only locks down Zope 3 dependencies and defers to PyPI for the rest, but that doesn't sound ideal either. A pattern I've seen Tres advocate is of using a custom index per project containing exactly those packages the project needs - how much help would a ZTK index be to support that use case? Regards, Martijn
Martijn Faassen wrote:
Whether ztk.cfg can be reused directly or whether we should extract something in it with just the version indicators I'm not sure about. I've noticed when modifying the buildout.cfg of the ZTK to add z3c.recipe.depgraph support that I had to pin down *everything* that was pulled in by depgraph as well if I wanted to avoid getting buildout errors (some weird version conflict was taking place). I hope that ztk.cfg isn't triggering that.
I'd say it does; it contains a line allow-picked-versions = false which makes buildout complain if it ends up using a package whose version it had to pick from the index, so you're required to specify a version for every package used by any part of the buildout. This line is a piece of policy that I'd like to see gone from ztk.cfg as well; if someone wants the behaviour, they can specify it in their buildout.cfg.
The reason I mentioned docs.zope.org as the release location is because we will also publish release-specific ZTK documentation when we make a release. The release-specific documentation should be maintained and tagged along with the ZTK itself, and we should have easy access to previous versions of the docs on versioned URLs.
Agreed. -- Thomas
Thomas Lotze wrote:
Martijn Faassen wrote:
Whether ztk.cfg can be reused directly or whether we should extract something in it with just the version indicators I'm not sure about. I've noticed when modifying the buildout.cfg of the ZTK to add z3c.recipe.depgraph support that I had to pin down *everything* that was pulled in by depgraph as well if I wanted to avoid getting buildout errors (some weird version conflict was taking place). I hope that ztk.cfg isn't triggering that.
I'd say it does; it contains a line
allow-picked-versions = false
which makes buildout complain if it ends up using a package whose version it had to pick from the index, so you're required to specify a version for every package used by any part of the buildout. This line is a piece of policy that I'd like to see gone from ztk.cfg as well; if someone wants the behaviour, they can specify it in their buildout.cfg.
Agreed. We need to know why it's there first. I'll ask. Regards, Martijn
On 10/05/2009 02:22 PM, Martijn Faassen wrote:
Thomas Lotze wrote:
Having worked on and released new versions of a few ZTK packages recently, I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as there doesn't seem to be an agreed process about this and in an attempt not to step on anyone's toes, I'd like to ask first whether it is OK for any developer to modify the versions listed in ztk.cfg (provided that all relevant tests are passing, of course). I'd currently like to update the following packages:
zope.app.apidoc = 3.6.7 zope.app.publication = 3.9.0 zope.error = 3.7.0 zope.location = 3.7.0 zope.site = 3.7.0 zope.traversing = 3.8.0
Thanks for bringing this up.
There's indeed currently no agreed-upon process. Jim a while ago was proposing a rather heavy staging process where the trunk can only be changed if a staged branch passed all tests on all platforms (and Python versions) as run by a buildbot. We don't have the infrastructure for this yet and Christian Theune and I were wondering whether this is needed.
An alternative process would be to only *release* the ZTK after the compat tests run on all platforms as shown by the buildbot. We do have infrastructure for that.
So I'd propose the following development process:
* developers can change the version numbers in the ZTK
* if the compattests all run, they can check in
And then for releases:
* we determine we want to make a release of the ZTK
* if the buildbot reports it all works on all platforms
* we verify there have been no further modifications since then
* we can release
* what does a release look like exactly? We should at least have a documentation release sitting somewhere on docs.zope.org, with the release number in the URL. The 'current' URL should also point to this documentation. Along with this we should also publish the lists of versions for reuse. How?
I would agree with that as a basis for getting started. I think during the course of making the first pre-releases for the ZTK we'll be able to spot issues with that and improve further. Christian -- Christian Theune · ct@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
participants (4)
-
Christian Theune -
Hanno Schlichting -
Martijn Faassen -
Thomas Lotze