movedaddedremoved branches of zope.container and zope.lifecycleevent
I've created two codependent branches of zope.container and zope.lifecyclevent: http://svn.zope.org/zope.container/branches/movedaddedremoved/ http://svn.zope.org/zope.lifecycleevent/branches/movedaddedremoved/ The intent was to move ``IObjectMovedEvent``, ``IObjectAddedEvent``, ``IObjectRemovedEvent`` interfaces and ``ObjectMovedEvent``, ``ObjectAddedEvent`` and ``ObjectRemovedEvent`` to the ``zope.lifecycleevent`` event package. Merging this would allow us to reduce dependencies on zope.container in other packages (instead, those packages would just depend on zope.lifecycleevent, which has very few dependencies). zope.intid is one such package (although it still will have one niggling dependency on "IContained" from zope.container even after it started to import event stuff from zope.lifecycleevent) I don't know if merging this stuff is reasonable. I do understand the difference between "lifecycle events" and "container events" and the events I moved out are definitely container events. I just wonder if it matters to be completely correct terminology-wise here. The other alternative is to create another package. - C
Chris McDonough wrote:
I've created two codependent branches of zope.container and zope.lifecyclevent:
[...]
I don't know if merging this stuff is reasonable. I do understand the difference between "lifecycle events" and "container events" and the events I moved out are definitely container events. I just wonder if it matters to be completely correct terminology-wise here. The other alternative is to create another package.
+1 on merging. I found it rather annoying so far to look for these interfaces in different places. To me it belongs to the lifecycle of an object to be part of a container. Hanno
Hanno Schlichting wrote:
Chris McDonough wrote:
I've created two codependent branches of zope.container and zope.lifecyclevent:
[...]
I don't know if merging this stuff is reasonable. I do understand the difference between "lifecycle events" and "container events" and the events I moved out are definitely container events. I just wonder if it matters to be completely correct terminology-wise here. The other alternative is to create another package.
+1 on merging.
I found it rather annoying so far to look for these interfaces in different places. To me it belongs to the lifecycle of an object to be part of a container.
+1 too. Even though formally it might indeed be that these events are only container related, I did have the same frustration Hanno describes - these are very common events and often you want to subscribe to them and IObjectModified which is already in zope.lifecyclevents. Regards, Martijn
On 5/15/09 7:33 AM, Martijn Faassen wrote:
Hanno Schlichting wrote:
Chris McDonough wrote:
I've created two codependent branches of zope.container and zope.lifecyclevent: [...]
I don't know if merging this stuff is reasonable. I do understand the difference between "lifecycle events" and "container events" and the events I moved out are definitely container events. I just wonder if it matters to be completely correct terminology-wise here. The other alternative is to create another package. +1 on merging.
I found it rather annoying so far to look for these interfaces in different places. To me it belongs to the lifecycle of an object to be part of a container.
+1 too. Even though formally it might indeed be that these events are only container related, I did have the same frustration Hanno describes - these are very common events and often you want to subscribe to them and IObjectModified which is already in zope.lifecyclevents.
These branches were merged. I made a new release of zope.lifecycleevent (3.5.2) to PyPI. zope.container does not have a new release yet. I may try to move IContained out of it (to zope.location) then make a new release. - C
Chris McDonough wrote:
These branches were merged. I made a new release of zope.lifecycleevent (3.5.2) to PyPI.
Thanks very much for doing this work. As a reminder for the future, please do release changes in the API (as in zope.lifecycleevent) as major releases (i.e. 3.6). I realize this requires an extra consideration when releasing that people seem to forget to do, so I've just adjusted the release instructions to make a note of this: (might not have shown up on the web yet, but will soon, step 2) http://docs.zope.org/zopetoolkit/process/releasing-software.html Regards, Martijn
I don't currently have access to publish zope.intid, but I think it's probably ready for a release too, BTW. - C On 5/17/09 1:34 PM, Martijn Faassen wrote:
Chris McDonough wrote:
These branches were merged. I made a new release of zope.lifecycleevent (3.5.2) to PyPI.
Thanks very much for doing this work.
As a reminder for the future, please do release changes in the API (as in zope.lifecycleevent) as major releases (i.e. 3.6).
I realize this requires an extra consideration when releasing that people seem to forget to do, so I've just adjusted the release instructions to make a note of this:
(might not have shown up on the web yet, but will soon, step 2)
http://docs.zope.org/zopetoolkit/process/releasing-software.html
Regards,
Martijn
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Chris McDonough wrote:
I don't currently have access to publish zope.intid, but I think it's probably ready for a release too, BTW.
I just gave you access to this package. Stephan has a script by the way that can give you access to a wide range of packages, might be a good idea if he ran it. :) Regards, Martijn
On 5/18/09 6:42 AM, Martijn Faassen wrote:
Chris McDonough wrote:
I don't currently have access to publish zope.intid, but I think it's probably ready for a release too, BTW.
I just gave you access to this package. Stephan has a script by the way that can give you access to a wide range of packages, might be a good idea if he ran it. :)
Thanks. zope.intid 3.7.1 (which depends on zope.lifecycleevent>=3.5.2 and zope.location>=3.5.4) has been released. - C
Chris McDonough wrote:
On 5/18/09 6:42 AM, Martijn Faassen wrote:
Chris McDonough wrote:
I don't currently have access to publish zope.intid, but I think it's probably ready for a release too, BTW. I just gave you access to this package. Stephan has a script by the way that can give you access to a wide range of packages, might be a good idea if he ran it. :)
Thanks.
zope.intid 3.7.1 (which depends on zope.lifecycleevent>=3.5.2 and zope.location>=3.5.4) has been released.
Thanks. But: why is this not zope.intid 3.8? It's clearly not a bugfix release. Regards, Martijn
On 5/19/09 6:49 AM, Martijn Faassen wrote:
Chris McDonough wrote:
On 5/18/09 6:42 AM, Martijn Faassen wrote:
Chris McDonough wrote:
I don't currently have access to publish zope.intid, but I think it's probably ready for a release too, BTW. I just gave you access to this package. Stephan has a script by the way that can give you access to a wide range of packages, might be a good idea if he ran it. :) Thanks.
zope.intid 3.7.1 (which depends on zope.lifecycleevent>=3.5.2 and zope.location>=3.5.4) has been released.
Thanks.
But: why is this not zope.intid 3.8? It's clearly not a bugfix release.
Er, it actually isn't a major release. None of *its* interfaces moved. I thought we were defining "major release" as "API change". - C
Chris McDonough wrote: [snip]
Er, it actually isn't a major release. None of *its* interfaces moved. I thought we were defining "major release" as "API change".
Hm, a dependency change isn't a bugfix either. It's an edge case, and one where I think we should err on the side of caution. It's a change in behavior that could have more consequences than the normally bugfix, though less consequences than API change. It could be argued that a change in dependencies *is* a feature change. Less might be registered. People might depend on implicit dependencies being present (even though they shouldn't). Less might be monkey-patched... It was recorded here previously: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html "Moving code around as part of dependency refactoring is worth a feature release (x.y as opposed to x.y.z version number) for the affected packages. Changing an import to make use of a new package that came out of such refactoring is also worth a feature release." Regards, Martijn
On 5/19/09 11:06 AM, Martijn Faassen wrote:
Chris McDonough wrote: [snip]
Er, it actually isn't a major release. None of *its* interfaces moved. I thought we were defining "major release" as "API change".
Hm, a dependency change isn't a bugfix either.
It's an edge case, and one where I think we should err on the side of caution. It's a change in behavior that could have more consequences than the normally bugfix, though less consequences than API change.
It could be argued that a change in dependencies *is* a feature change. Less might be registered. People might depend on implicit dependencies being present (even though they shouldn't). Less might be monkey-patched...
It was recorded here previously:
http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html
"Moving code around as part of dependency refactoring is worth a feature release (x.y as opposed to x.y.z version number) for the affected packages. Changing an import to make use of a new package that came out of such refactoring is also worth a feature release."
OK, noted. Thanks, - C
participants (3)
-
Chris McDonough -
Hanno Schlichting -
Martijn Faassen