Re: [Zope-dev] SVN: zope.file/branches/ulif-fix-menus/ Do menu-related configuration only if z.a.zcmlfiles is available.
On 05/27/2012 07:36 PM, Ulrich Fouquet wrote:
Log message for revision 126504: Do menu-related configuration only if z.a.zcmlfiles is available.
Changed: U zope.file/branches/ulif-fix-menus/CHANGES.txt U zope.file/branches/ulif-fix-menus/src/zope/file/browser.zcml
Hmmm, looks like you forgot to 'svn add src/zope/file/menu.zcml'. Tres. -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On Sun, 27 May 2012 21:09:44 -0400 Tres Seaver wrote:
On 05/27/2012 07:36 PM, Ulrich Fouquet wrote:
Log message for revision 126504: Do menu-related configuration only if z.a.zcmlfiles is available.
Changed: U zope.file/branches/ulif-fix-menus/CHANGES.txt U zope.file/branches/ulif-fix-menus/src/zope/file/browser.zcml
Hmmm, looks like you forgot to 'svn add src/zope/file/menu.zcml'.
I was convinced I did, but apparently I didn't. It's in now. Thanks for the hint! The branch (ulif-fix-menus) could be reviewed now, although there is not much to review. I didn't manage to create a reasonable regression test for the use case, as it seems to be very difficult and complex to remove some installed package and make it temporarily unimportable. If someone has an idea how to do this with not too much effort, I'd be glad to add it. Simply changing sys.modules and sys.path seems not to be enough. If this test would be not crucial, I'd leave it this way and prepare a minor release, maybe with some additional changes (the buildout.cfg is a bit outdated and test coverage could be improved otherwise). Best regards, -- Uli
+1 for merging On Mon, May 28, 2012 at 11:16 AM, Uli Fouquet <uli@gnufix.de> wrote:
On Sun, 27 May 2012 21:09:44 -0400 Tres Seaver wrote:
On 05/27/2012 07:36 PM, Ulrich Fouquet wrote:
Log message for revision 126504: Do menu-related configuration only if z.a.zcmlfiles is available.
Changed: U zope.file/branches/ulif-fix-menus/CHANGES.txt U zope.file/branches/ulif-fix-menus/src/zope/file/browser.zcml
Hmmm, looks like you forgot to 'svn add src/zope/file/menu.zcml'.
I was convinced I did, but apparently I didn't. It's in now.
Thanks for the hint!
The branch (ulif-fix-menus) could be reviewed now, although there is not much to review.
I didn't manage to create a reasonable regression test for the use case, as it seems to be very difficult and complex to remove some installed package and make it temporarily unimportable.
If someone has an idea how to do this with not too much effort, I'd be glad to add it. Simply changing sys.modules and sys.path seems not to be enough.
If this test would be not crucial, I'd leave it this way and prepare a minor release, maybe with some additional changes (the buildout.cfg is a bit outdated and test coverage could be improved otherwise).
Best regards,
-- Uli
_______________________________________________ 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 )
Hi Leo, On Sun, 3 Jun 2012 23:18:49 +0200 Leonardo Rochael Almeida wrote:
+1 for merging
Great, thanks for looking into this! I'd be happy to merge and maybe increase test-coverage. Maybe someone could then do the zope.file 0.6.2 release or grant PyPI permissions for 'ulif'. Best regards, -- Uli
Am 04.06.2012 um 14:11 schrieb Uli Fouquet: […]
Maybe someone could then do the zope.file 0.6.2 release or grant PyPI permissions for 'ulif'.
Access granted. Mit freundlichen Grüßen -- Michael Howitz · mh@gocept.com · Softwareentwickler gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Deutschland http://gocept.com · Tel +49 345 1229889 8 · Fax +49 345 1229889 1 Beratung, Entwicklung und Hosting für Python, Pyramid, Zope, und Plone
Hi Michael, On Mon, 4 Jun 2012 16:02:52 +0200 Michael Howitz wrote:
Am 04.06.2012 um 14:11 schrieb Uli Fouquet: […]
Maybe someone could then do the zope.file 0.6.2 release or grant PyPI permissions for 'ulif'.
Access granted.
Thanks a lot, 0.6.2 released. Also updated the 0.6 branch in SVN. Hope that's okay. Best regards, -- Uli
Am 04.06.2012 um 18:30 schrieb Uli Fouquet: […]
Also updated the 0.6 branch in SVN. Hope that's okay.
I think there should not be a 0.6 branch as the trunk is still on 0.6.*. Usually we only create maintenance branches for non-current releases. Mit freundlichen Grüßen -- Michael Howitz · mh@gocept.com · Softwareentwickler gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Deutschland http://gocept.com · Tel +49 345 1229889 8 · Fax +49 345 1229889 1 Beratung, Entwicklung und Hosting für Python, Pyramid, Zope, und Plone
On 06/05/2012 03:28 AM, Michael Howitz wrote:
Am 04.06.2012 um 18:30 schrieb Uli Fouquet: […]
Also updated the 0.6 branch in SVN. Hope that's okay.
I think there should not be a 0.6 branch as the trunk is still on 0.6.*. Usually we only create maintenance branches for non-current releases.
That isn't true any longer for the ZTK packages: I added maintenance branches for all the versions used by ZTK 1.0 / 1.1, and switched the development checkouts for 1.0 / 1.1. to use them. Without that change, the stop-energy of "breaking" a dev build for 1.0 / 1.1 was interfering with ongoing development. In this case, version 0.6.1 of the zope.file package was included in ZTK 1.0, but dropped from the ZTK before 1.1. I'm pretty sure the changes Uli added should *not* be propagated into another ZTK 1.0 release: I think they might break apps deployed against ZTK 1.0: Because of the BBB concerns, I think we may need to re-release a 0.6.3 which reverts the 0.6 branch back to the 0.6.1 state, and make Uli's new stuff available as a 0.7.0 release. Tres. -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Hi there, On Tue, 05 Jun 2012 03:53:19 -0400 Tres Seaver wrote:
On 06/05/2012 03:28 AM, Michael Howitz wrote:
Am 04.06.2012 um 18:30 schrieb Uli Fouquet: […]
Also updated the 0.6 branch in SVN. Hope that's okay.
I think there should not be a 0.6 branch as the trunk is still on 0.6.*. Usually we only create maintenance branches for non-current releases.
Yes, the existence of such a branch surprised me too.
That isn't true any longer for the ZTK packages: I added maintenance branches for all the versions used by ZTK 1.0 / 1.1, and switched the development checkouts for 1.0 / 1.1. to use them. Without that change, the stop-energy of "breaking" a dev build for 1.0 / 1.1 was interfering with ongoing development.
I see, interesting. But that means a stop-energy for releasing any bugfix release of ZTK packages, doesn't it? At least that seems to be the case if even such minimal changes, that do not change the package API at all, are considered to break the ZTK. I also wonder a bit, why it is neccessary to maintain a 'ZTK-branch' named like a regular maintenance branch, at least for maintenance branches that match the trunk version. Shouldn't that be named 'ztk-compat', 'ztk-1.0-compat' or similar then? Beside this I thought one major point of dev-builds for ZTKs is to _see_ changes in ongoing development of packages that break ZTK-compatibility. Now you can see such breakages only after a release and when these maintenance branches were updated (or, of course, if one does the ztk tests with local changes before release, which I did - without any issues).
In this case, version 0.6.1 of the zope.file package was included in ZTK 1.0, but dropped from the ZTK before 1.1. I'm pretty sure the changes Uli added should *not* be propagated into another ZTK 1.0 release: I think they might break apps deployed against ZTK 1.0: Because of the BBB concerns, I think we may need to re-release a 0.6.3 which reverts the 0.6 branch back to the 0.6.1 state, and make Uli's new stuff available as a 0.7.0 release.
As the menu config has not gone from 0.6.2 but is only activated conditionally, I am relatively sure, that there are no BBB problems with 0.6.2. Everyone who used 0.6.1 should also be able to use 0.6.2 without any changes to local apps/configs. Or did I miss something here? The (unconditional) _removal_ of menu configuration might indeed be part of some 0.7.x or even 1.0 release, just as Leo suggested. But that didn't happen yet. I also ran ztk tests (Linux/64bit, Python2.7) with 0.6.2 against ZTKs 1.0, 1.0.7, 1.0dev and got exactly same errors as with 0.6.1 (mainly related to Python version, no hints to problems with 0.6.2). I am not strictly against reverting all the stuff and going to 0.7, but 'pinning' a package version this way and for these reasons seems, hm, not very effective to me. Best regards, -- Uli
On 06/05/2012 06:36 AM, Uli Fouquet wrote:
Hi there,
On Tue, 05 Jun 2012 03:53:19 -0400 Tres Seaver wrote:
On 06/05/2012 03:28 AM, Michael Howitz wrote:
Am 04.06.2012 um 18:30 schrieb Uli Fouquet: […]
Also updated the 0.6 branch in SVN. Hope that's okay.
I think there should not be a 0.6 branch as the trunk is still on 0.6.*. Usually we only create maintenance branches for non-current releases.
Yes, the existence of such a branch surprised me too.
That isn't true any longer for the ZTK packages: I added maintenance branches for all the versions used by ZTK 1.0 / 1.1, and switched the development checkouts for 1.0 / 1.1. to use them. Without that change, the stop-energy of "breaking" a dev build for 1.0 / 1.1 was interfering with ongoing development.
I see, interesting. But that means a stop-energy for releasing any bugfix release of ZTK packages, doesn't it? At least that seems to be the case if even such minimal changes, that do not change the package API at all, are considered to break the ZTK.
I apologise if I misunderstood the BBB implications of your zope.file work: I thought I understood that existing apps might need changes to keep the menu registrations active.
I also wonder a bit, why it is neccessary to maintain a 'ZTK-branch' named like a regular maintenance branch, at least for maintenance branches that match the trunk version.
It *is* a maintenance branch (the branch from which 0.6.x releases really ought to be made). The fact that the trunk had not (yet) diverged was merely a happy accident.
Shouldn't that be named 'ztk-compat', 'ztk-1.0-compat' or similar then?
I disagreed with the "just release from the trunk" choice earlier, but went along with it: we kept having cases where feature work on the trunk would break tests in the "released" ZTK dev buildouts. As the number of incompatible trunks grew (e.g., dropping compatiblitiy tieh Ptyhon 2.4 / 2.5), it finally became too big a drag on that development to have the "released" ZTK dev tests using trunks.
Beside this I thought one major point of dev-builds for ZTKs is to _see_ changes in ongoing development of packages that break ZTK-compatibility.
Not for *released* ZTK versions: that should only be so for the ZTK trunk itself.
Now you can see such breakages only after a release and when these maintenance branches were updated (or, of course, if one does the ztk tests with local changes before release, which I did - without any issues).
We should *not* be looking for the ZTK 1.0 / 1.1 dev buildouts to tell us that we have "broken" something on a trunk: new versions of ZTK 1.0.x / 1.1.x should be *very* conservative, accepting only true bugfix updates to their packages.
In this case, version 0.6.1 of the zope.file package was included in ZTK 1.0, but dropped from the ZTK before 1.1. I'm pretty sure the changes Uli added should *not* be propagated into another ZTK 1.0 release: I think they might break apps deployed against ZTK 1.0: Because of the BBB concerns, I think we may need to re-release a 0.6.3 which reverts the 0.6 branch back to the 0.6.1 state, and make Uli's new stuff available as a 0.7.0 release.
As the menu config has not gone from 0.6.2 but is only activated conditionally, I am relatively sure, that there are no BBB problems with 0.6.2. Everyone who used 0.6.1 should also be able to use 0.6.2 without any changes to local apps/configs. Or did I miss something here?
The (unconditional) _removal_ of menu configuration might indeed be part of some 0.7.x or even 1.0 release, just as Leo suggested. But that didn't happen yet.
I also ran ztk tests (Linux/64bit, Python2.7) with 0.6.2 against ZTKs 1.0, 1.0.7, 1.0dev and got exactly same errors as with 0.6.1 (mainly related to Python version, no hints to problems with 0.6.2).
I am not strictly against reverting all the stuff and going to 0.7, but 'pinning' a package version this way and for these reasons seems, hm, not very effective to me.
Again, I apologise for my misunderstanding. If you are confident that existing apps won't need any changes when upgrading to 0.6.2, then we shouldn't need to shuffle the releases. Tres. -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Am 05.06.2012 um 09:53 schrieb Tres Seaver:
On 06/05/2012 03:28 AM, Michael Howitz wrote:
Am 04.06.2012 um 18:30 schrieb Uli Fouquet: […]
Also updated the 0.6 branch in SVN. Hope that's okay.
I think there should not be a 0.6 branch as the trunk is still on 0.6.*. Usually we only create maintenance branches for non-current releases.
That isn't true any longer for the ZTK packages: I added maintenance branches for all the versions used by ZTK 1.0 / 1.1, and switched the development checkouts for 1.0 / 1.1. to use them. Without that change, the stop-energy of "breaking" a dev build for 1.0 / 1.1 was interfering with ongoing development.
In this case, version 0.6.1 of the zope.file package was included in ZTK 1.0, but dropped from the ZTK before 1.1. I'm pretty sure the changes Uli added should *not* be propagated into another ZTK 1.0 release: I think they might break apps deployed against ZTK 1.0: Because of the BBB concerns, I think we may need to re-release a 0.6.3 which reverts the 0.6 branch back to the 0.6.1 state, and make Uli's new stuff available as a 0.7.0 release.
I thought the same way but I looked at the changes: now only if zope.app.zcmlfiles is there the menu items are registered which was done unconditionally before. I do not see why this should break any ZTK 1.0 apps. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations
participants (4)
-
Leonardo Rochael Almeida -
Michael Howitz -
Tres Seaver -
Uli Fouquet