Re: [Zope3-dev] package branches
On Jun 27, 2007, at 11:36 AM, Gary Poster wrote: On Jun 27, 2007, at 2:30 AM, Bernd Dorn wrote: On 26.06.2007, at 21:44, Gary Poster wrote: On Jun 26, 2007, at 3:29 PM, Bernd Dorn wrote: i think as long the package has a dev dependency like ZODB 3.9 it should at least have alpha or beta status Hi Bernd. Why? because it pulls in software that has development status like zodb 3.9 and the release of 3.9 will take at least a half a year from now on imho. My basic response--don't use this version of zope.app.keyreference--doesn't appear to be sufficient for you (or Theuni, from his Specifying upper limits in dependencies email today). I have asserted, and I think people agree that setting upper limits in setup scripts is a bad idea as it will soon lead to situations where the current algorithm used by setuptools to build working sets of compatible revisions will fail. Of course, it isn't a problem to introduce tighter version requirements in application setup scripts or buildout configurations. It is ok for me because my project is specifying versions, which is also the strategy he says he is pursuing. I don't know of a better one, actually. Both you and he seem to be looking for one though, which I appreciate. gary, is it possible to be compatible to 3.8 too? Not productively. We could have if the PersistentReference doesn't have the 3.9 stuff then just refuse to do a ConflictError but then that's no different that the keyreference 3.4 behavior. Heh, actually, that's effectively the behavior we probably have now for keyreference 3.5dev running against ZODB 3.8, since errors in the conflict resolution will simply cause the resolution to fail, and the 3.5dev changes would generate AttributeErrors against ZODB 3.8 during conflict resolution. So...it would be a bit of a lie to claim to be compatible with 3.8. The changes are useless without the 3.9 changes. But the code *should* technically work with the same restrictions we have now. That said, I don't really want to support the changes against 3.8. ...I could move the releases to our ZC download location, rather than the zope.org one, if folks want... i don't think that this is a good idea, for example our company uses both of the download locations Well, I can move it any number of places, but this does sound like a hack, hiding the basic problem. Yup. What's the problem? I'm happy to help, especially if it doesn't take too much time, and you can wait a day or two. ok, i think if another new feature is implemented in keyreference and we want this feature for zodb3.8 we have to do a version inbetween, so if you call this a 3.5 release, what should that other version be? 3.6 I guess this is a problem. I certainly understand the story. We (the community/dev mailing list) had said before that you needed to start a new major version when you broke backwards compatibility. I did not break backwards compatibility, I just depended on a new feature of another package. The only answer I see to solve the story you just told is to also say that you have to rev the major version whenever you depend on the new feature of another package. I think that in *technically* depending on a newer version introduces a backward incompatibility. (It's like strengthening a precondition of a method.) This is especially a problem if people are specifying upper limits for their requirements, which is only necessary if there backward incompatible changes. ZODB 3.9 won't be backward incompatible in any meaningful way. ZODB 3.9, like 3.8 *is* backward incompatible because it drops features that we agreed, as a community, to drop. Arguably, ZODB 3.8 should have been ZODB 4 and ZODB 3.9 should be ZODB 5, but I don't think we want to do that. So, let''s say, as a practical matter, that ZODB 3.9 is backward compatible with 3.8. We don't know that 3.9 is ready for use yet. It's possible that there have been bugs introduced in 3.9 (or soon will be) that will be discovered and fixed during the beta cycle. Many people rightly don't want to depend on 3.9 until it has been released in a final form. Bernd has suggested a policy that I think we should adopt, which is that a package's release status should be no higher than the status of it's dependencies. So, for example, if A depends on a dev version of B, then the version of A that has this dependency should be a dev version. A should not be able to go to alpha, or beta, or final without a corresponding advance of its dependency on B. However, I am afraid that this would lead to ugly (and expensive to maintain) if-else clauses in our software, or rapidly escalating version numbers, and even maintaining multiple branches simultaneously. Dependencies are precisely what is supposed to address this problem, I thought. Except we've found corners in the dependency
Re: [Zope3-dev] package branches
On Jul 2, 2007, at 9:42 PM, Jim Fulton wrote: Thanks for reply. quick notes: I think that in *technically* depending on a newer version introduces a backward incompatibility. (It's like strengthening a precondition of a method.) This is especially a problem if people are specifying upper limits for their requirements, which is only necessary if there backward incompatible changes. ZODB 3.9 won't be backward incompatible in any meaningful way. ZODB 3.9, like 3.8 *is* backward incompatible because it drops features that we agreed, as a community, to drop. Arguably, ZODB 3.8 should have been ZODB 4 and ZODB 3.9 should be ZODB 5, but I don't think we want to do that. So, let''s say, as a practical matter, that ZODB 3.9 is backward compatible with 3.8. We don't know that 3.9 is ready for use yet. It's possible that there have been bugs introduced in 3.9 (or soon will be) that will be discovered and fixed during the beta cycle. Many people rightly don't want to depend on 3.9 until it has been released in a final form. Bernd has suggested a policy that I think we should adopt, which is that a package's release status should be no higher than the status of it's dependencies. So, for example, if A depends on a dev version of B, then the version of A that has this dependency should be a dev version. A should not be able to go to alpha, or beta, or final without a corresponding advance of its dependency on B. Unless I misunderstand, this is what I did, actually, and Bernd (and probably others) didn't like it. That is, I have a zope.org/ distributions release of zope.app.keyreference 3.5 dev and ZODB 3.9 dev, and I said that keyreference 3.5 depended on ZODB 3.9 dev. I like the proposal you and Benji came up with. In that case, would what I released (except that I used -dev rather than dev) be correct? ... - For this particular problem, I wish my ZODB changes could go into ZODB 3.8. As I mentioned in the commit message, the change includes one bug fix for a potentially serious problem that could cause data integrity issues; This could go into 3.8. one new feature (more informative PersisntentReferences) that supports an arguable zope.app.keyreference bugfix (conflict resolution breaks with persistent key references; Can you remind me or point me at something that describes in more detail? ZODB/ConflictResolution.txt line 226 ff. Does zope.app.keyreference work as well as it does now without this? I haven't tested it, but yes, I believe it should. and one feature (conflict resolution now supports multi databases). This is a bug fix and could go into 3.8. Then I'd argue that the zope.app.keyreference change could go into 3.4. Are we really talking about 3.4? Yes, zope.app.keyreference. Not breaking BTree conflict resolution could be cast pretty easily as a bugfix. - Even if people agreed with me for the previous bullet, that doesn't make this kind of problem go away. - Also for this particular problem, I suppose I could remove the dependency on ZODB 3.9 and add a test to show that it should still work (as well as it did before at least) with ZODB 3.8 persistent references. I'd really rather not, of course, but I can do it in the next week and a half. I guess it would still be 3.5 but it wouldn't depend on 3.9 (...except to actually have any improvements over 3.4!) I think you should do this or make your version of zope.app.keyreference a dev version. OK, I'll see what I can do ... My current opinion is that version numbers are the best solution of a bad lot. I think we really need a way to limit the algorithm for finding distributions to avoid immature (releases). I just brainstormed this with Benji and we both think that it would be enough to have an option that says: I prefer final versions meaning that we always want the latest final version that satisfies our requirements, if there is one. Ideally, this would be a setuptools option, however, this would be a new feature and I don't think we'll see new setuptools features any time soon. I could add this as an option to buildout. sounds good to me. Being able to override it for individual packages would be important for me. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
Gary Poster wrote: In that case, would what I released (except that I used -dev rather than dev) be correct? Yep. And those that only want final releases would be required to say so when invoking setuptools (or buildout). -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On Jul 2, 2007, at 3:07 PM, Gary Poster wrote: ... Bernd has suggested a policy that I think we should adopt, which is that a package's release status should be no higher than the status of it's dependencies. So, for example, if A depends on a dev version of B, then the version of A that has this dependency should be a dev version. A should not be able to go to alpha, or beta, or final without a corresponding advance of its dependency on B. Unless I misunderstand, this is what I did, actually, and Bernd (and probably others) didn't like it. That is, I have a zope.org/ distributions release of zope.app.keyreference 3.5 dev and ZODB 3.9 dev, and I said that keyreference 3.5 depended on ZODB 3.9 dev. Cool. I guess I missed that. ... I like the proposal you and Benji came up with. In that case, would what I released (except that I used -dev rather than dev) be correct? Yes ... one new feature (more informative PersisntentReferences) that supports an arguable zope.app.keyreference bugfix (conflict resolution breaks with persistent key references; Can you remind me or point me at something that describes in more detail? ZODB/ConflictResolution.txt line 226 ff. I think the __cmp__ method is a bug fix. Would that be enough for zope.app.keyreference? ... Does zope.app.keyreference work as well as it does now without this? I haven't tested it, but yes, I believe it should. Then if we back-ported the bug fixes, as I think we should, then zope.app.keyreference could depend on 3.8, or perhaps even 3.7. ... Then I'd argue that the zope.app.keyreference change could go into 3.4. Are we really talking about 3.4? Yes, zope.app.keyreference. Not breaking BTree conflict resolution could be cast pretty easily as a bugfix. I'm still not sure what this has to do with 3.4. :) ... - Also for this particular problem, I suppose I could remove the dependency on ZODB 3.9 and add a test to show that it should still work (as well as it did before at least) with ZODB 3.8 persistent references. I'd really rather not, of course, but I can do it in the next week and a half. I guess it would still be 3.5 but it wouldn't depend on 3.9 (...except to actually have any improvements over 3.4!) I think you should do this or make your version of zope.app.keyreference a dev version. OK, I'll see what I can do It sounds like it already is a dev version. ... I just brainstormed this with Benji and we both think that it would be enough to have an option that says: I prefer final versions meaning that we always want the latest final version that satisfies our requirements, if there is one. Ideally, this would be a setuptools option, however, this would be a new feature and I don't think we'll see new setuptools features any time soon. I could add this as an option to buildout. sounds good to me. Being able to override it for individual packages would be important for me. You'd override it by specifying a needed dev version in a requirement. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On 26.06.2007, at 21:44, Gary Poster wrote: On Jun 26, 2007, at 3:29 PM, Bernd Dorn wrote: On 23.06.2007, at 12:38, Christian Theune wrote: Am Samstag, den 23.06.2007, 07:04 -0400 schrieb Gary Poster: Hey Christian. I intend to check in some code that fixes zope.app.keyreference conflict error issues I wrote about last week. This will take advantage of some code that I checked in to the ZODB, that I don't intend to be part of ZODB 3.8--so I don't intend my zope.app.keyreference changes to be part of Zope 3.4. The zope.app.keyreference package has not yet branched. In your capacity as release manager, would you mind if I did that, so I could make a 3.5 dev checkin/egg? Also, I'm a bit confused on our preference now: would this be 3.5.0-dev or 3.5.0a1-dev, or what? Yes. And if you're at it, I'd welcome if you'd switch the tree's trunk to use that branch. :) The trunk's setup.py of the satellite should either be 3.5.0a1 or 3.5.0. i think as long the package has a dev dependency like ZODB 3.9 it should at least have alpha or beta status Hi Bernd. Why? because it pulls in software that has development status like zodb 3.9 and the release of 3.9 will take at least a half a year from now on imho. gary, is it possible to be compatible to 3.8 too? Not productively. We could have if the PersistentReference doesn't have the 3.9 stuff then just refuse to do a ConflictError but then that's no different that the keyreference 3.4 behavior. Heh, actually, that's effectively the behavior we probably have now for keyreference 3.5dev running against ZODB 3.8, since errors in the conflict resolution will simply cause the resolution to fail, and the 3.5dev changes would generate AttributeErrors against ZODB 3.8 during conflict resolution. So...it would be a bit of a lie to claim to be compatible with 3.8. The changes are useless without the 3.9 changes. But the code *should* technically work with the same restrictions we have now. That said, I don't really want to support the changes against 3.8. ...I could move the releases to our ZC download location, rather than the zope.org one, if folks want... i don't think that this is a good idea, for example our company uses both of the download locations What's the problem? I'm happy to help, especially if it doesn't take too much time, and you can wait a day or two. ok, i think if another new feature is implemented in keyreference and we want this feature for zodb3.8 we have to do a version inbetween, so if you call this a 3.5 release, what should that other version be? 3.6 we use egg based releases and if you hardcode the zodb 3.9 dependency in setup.py we have to switch to zodb3.9 just because of that package if we want to use a new feature of it maybe i am anticipating here and it's best to make it zodb 3.8 compatible when we need a newer version of keyreference for some reason. the problem with this is, that we (zope committers) can do this, but another company may not be able to change the package. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On Jun 27, 2007, at 2:30 AM, Bernd Dorn wrote: On 26.06.2007, at 21:44, Gary Poster wrote: On Jun 26, 2007, at 3:29 PM, Bernd Dorn wrote: i think as long the package has a dev dependency like ZODB 3.9 it should at least have alpha or beta status Hi Bernd. Why? because it pulls in software that has development status like zodb 3.9 and the release of 3.9 will take at least a half a year from now on imho. My basic response--don't use this version of zope.app.keyreference-- doesn't appear to be sufficient for you (or Theuni, from his Specifying upper limits in dependencies email today). It is ok for me because my project is specifying versions, which is also the strategy he says he is pursuing. I don't know of a better one, actually. Both you and he seem to be looking for one though, which I appreciate. gary, is it possible to be compatible to 3.8 too? Not productively. We could have if the PersistentReference doesn't have the 3.9 stuff then just refuse to do a ConflictError but then that's no different that the keyreference 3.4 behavior. Heh, actually, that's effectively the behavior we probably have now for keyreference 3.5dev running against ZODB 3.8, since errors in the conflict resolution will simply cause the resolution to fail, and the 3.5dev changes would generate AttributeErrors against ZODB 3.8 during conflict resolution. So...it would be a bit of a lie to claim to be compatible with 3.8. The changes are useless without the 3.9 changes. But the code *should* technically work with the same restrictions we have now. That said, I don't really want to support the changes against 3.8. ...I could move the releases to our ZC download location, rather than the zope.org one, if folks want... i don't think that this is a good idea, for example our company uses both of the download locations Well, I can move it any number of places, but this does sound like a hack, hiding the basic problem. What's the problem? I'm happy to help, especially if it doesn't take too much time, and you can wait a day or two. ok, i think if another new feature is implemented in keyreference and we want this feature for zodb3.8 we have to do a version inbetween, so if you call this a 3.5 release, what should that other version be? 3.6 I guess this is a problem. I certainly understand the story. We (the community/dev mailing list) had said before that you needed to start a new major version when you broke backwards compatibility. I did not break backwards compatibility, I just depended on a new feature of another package. The only answer I see to solve the story you just told is to also say that you have to rev the major version whenever you depend on the new feature of another package. However, I am afraid that this would lead to ugly (and expensive to maintain) if-else clauses in our software, or rapidly escalating version numbers, and even maintaining multiple branches simultaneously. Dependencies are precisely what is supposed to address this problem, I thought. we use egg based releases and if you hardcode the zodb 3.9 dependency in setup.py we have to switch to zodb3.9 just because of that package if we want to use a new feature of it maybe i am anticipating here and it's best to make it zodb 3.8 compatible when we need a newer version of keyreference for some reason. the problem with this is, that we (zope committers) can do this, but another company may not be able to change the package. - Jim is not available to comment right now, AFAIK. I'm sure he'll have some thoughts here. - For this particular problem, I wish my ZODB changes could go into ZODB 3.8. As I mentioned in the commit message, the change includes one bug fix for a potentially serious problem that could cause data integrity issues; one new feature (more informative PersisntentReferences) that supports an arguable zope.app.keyreference bugfix (conflict resolution breaks with persistent key references; and one feature (conflict resolution now supports multi databases). Then I'd argue that the zope.app.keyreference change could go into 3.4. - Even if people agreed with me for the previous bullet, that doesn't make this kind of problem go away. - Also for this particular problem, I suppose I could remove the dependency on ZODB 3.9 and add a test to show that it should still work (as well as it did before at least) with ZODB 3.8 persistent references. I'd really rather not, of course, but I can do it in the next week and a half. I guess it would still be 3.5 but it wouldn't depend on 3.9 (...except to actually have any improvements over 3.4!) My current opinion is that version numbers are the best solution of a bad lot. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub:
Re: [Zope3-dev] package branches
Am Mittwoch, den 27.06.2007, 11:36 -0400 schrieb Gary Poster: My current opinion is that version numbers are the best solution of a bad lot. My current opinion is that we don't have a final story on how all the pieces we have now: multiple eggs with seperate lives, buildout, setuptools, version numbers and dependencies fall together. The problem I described in my other mail only touches one aspect. I feel like we don't have a coherent story yet, but I feel like we should have. I'd love to see some structured progress on this matter, but I probably should spend my time getting Zope 3.4 beta out of the door ... (Nevertheless, the whole egg story currently is groing a bit uncomfortable because e.g. testing integration etc. is becoming less and less obvious. That's another aspect.) Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On 23.06.2007, at 12:38, Christian Theune wrote: Am Samstag, den 23.06.2007, 07:04 -0400 schrieb Gary Poster: Hey Christian. I intend to check in some code that fixes zope.app.keyreference conflict error issues I wrote about last week. This will take advantage of some code that I checked in to the ZODB, that I don't intend to be part of ZODB 3.8--so I don't intend my zope.app.keyreference changes to be part of Zope 3.4. The zope.app.keyreference package has not yet branched. In your capacity as release manager, would you mind if I did that, so I could make a 3.5 dev checkin/egg? Also, I'm a bit confused on our preference now: would this be 3.5.0-dev or 3.5.0a1-dev, or what? Yes. And if you're at it, I'd welcome if you'd switch the tree's trunk to use that branch. :) The trunk's setup.py of the satellite should either be 3.5.0a1 or 3.5.0. i think as long the package has a dev dependency like ZODB 3.9 it should at least have alpha or beta status gary, is it possible to be compatible to 3.8 too? The 'dev' is a pre-release tag that is appended while making snapshots or continuous releases. The branch itself should state what the next real release will be. This depends a bit on the policy for each individual package. AS you remember, zope.app.keyreference 3.5.0 may not happen to have anything todo with Zope 3.5 ... Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/bernd.dorn% 40lovelysystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
Am Samstag, den 23.06.2007, 07:04 -0400 schrieb Gary Poster: Hey Christian. I intend to check in some code that fixes zope.app.keyreference conflict error issues I wrote about last week. This will take advantage of some code that I checked in to the ZODB, that I don't intend to be part of ZODB 3.8--so I don't intend my zope.app.keyreference changes to be part of Zope 3.4. The zope.app.keyreference package has not yet branched. In your capacity as release manager, would you mind if I did that, so I could make a 3.5 dev checkin/egg? Also, I'm a bit confused on our preference now: would this be 3.5.0-dev or 3.5.0a1-dev, or what? Yes. And if you're at it, I'd welcome if you'd switch the tree's trunk to use that branch. :) The trunk's setup.py of the satellite should either be 3.5.0a1 or 3.5.0. The 'dev' is a pre-release tag that is appended while making snapshots or continuous releases. The branch itself should state what the next real release will be. This depends a bit on the policy for each individual package. AS you remember, zope.app.keyreference 3.5.0 may not happen to have anything todo with Zope 3.5 ... Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] package branches
Hey Christian. I intend to check in some code that fixes zope.app.keyreference conflict error issues I wrote about last week. This will take advantage of some code that I checked in to the ZODB, that I don't intend to be part of ZODB 3.8--so I don't intend my zope.app.keyreference changes to be part of Zope 3.4. The zope.app.keyreference package has not yet branched. In your capacity as release manager, would you mind if I did that, so I could make a 3.5 dev checkin/egg? Also, I'm a bit confused on our preference now: would this be 3.5.0-dev or 3.5.0a1-dev, or what? Thanks Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
