Re: [Zope3-dev] A thought on backward compatibility and minimum versions
On May 31, 2007, at 2:47 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-5-31 14:15 -0400: ... I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. I agree, but this control should occur at at a different place. I suggest that when deploying or releasing an application or system, you want to fix all of the versions so that a released or deployed configuration is repeatable and so that changes are introduced in a controlled way. This can be done in a number of ways. You can have an application meta-package that specifies all of the versions, or, if you are using buildout, you can use buildout's facilities for fixing versions. For individual reusable "library packages", you want to make the dependencies as non-restrictive as possible so as to maximize flexibility and reusability. I agree but not to specify a minimal version and instead to assume that always the latest release version must be used does not maximize but reduce reusablitity. Look at the following szenario: In a given system module "A" is installed in version "M.m". For some reason, another module "B" in the system cannot work with "A" in any version "M.m'" with "m' > m". I think a ' is missing above. I assume you mean that B requires "A <=M.m". I know that this violates your assumption that any newer minor release is compatible with any older one (in the same major release). Unfortunately, such things happen Sure. For example, then A doesn't follow the rules and people will have to use an inconvenient specification for it. This will often be the case for non-Zope packages. For example, if Python was a distribution, it would, sadly, have this property. Now assume we want to install module "C" which needs "A" in version "M.*". Given the backward-compatibility policy of A, C's author has made an error. If "M.*" implicitly means: the newest minor release in the "M" series, then "C" cannot be installed in the hypothetical system. It means that any version of A in the M series should work. It doesn't mean that the latest is required. If the requirements of the "system" listed B before listing C, then a version of A compatible with B would get used and that would also work with C. If, on the other hand, if C is listed before B, then, using the current setuptools algorithm, the latest version of A will be used and will be incompatible with B. (Eventually, we'll switch to a better algorithm.) If, on the other hand, the dependency is expressed by "A >=M.m, <= M.", then "C" can be installed. Assuming that this is C's dependency, it doesn't make any difference. If C is named before B, you'll still get a version conflict. If your suppositions are only a form of introduction for the "M.*" syntax (or "M*", if you prefer) but does not affect the semantics of "M.*", i.e. if "M.*" means 'needs the module in *any* "M" version', then I have no objections. That's exactly what I meant. In fact, I meant exactly what I said, which was that: "project_name V.*" would be equivalent to "project_name >=V, 9" :) Even for me "M.*" is nicer than "M.9". More importantly, IMO, "A M.*" is nicer than "A >=M, 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] A thought on backward compatibility and minimum versions
Jim Fulton wrote at 2007-5-31 14:15 -0400: > ... >> I fear my colleagues responsible to maintain the productive versions >> would not be happy: >> >> They want the system to be as stable as possible. >> >> If they need to introduce a new component, they usually >> prefer to just add this one component. Only if this forces >> other updates, they reluctantly will make them. >> >> The motivation for this behaviour: even if a newer version >> is supposed to be backward compatible, it often has slightly different >> behaviour which may trigger bugs in the other parts of a complex >> system. > >I agree, but this control should occur at at a different place. I >suggest that when deploying or releasing an application or system, >you want to fix all of the versions so that a released or deployed >configuration is repeatable and so that changes are introduced in a >controlled way. This can be done in a number of ways. You can have >an application meta-package that specifies all of the versions, or, >if you are using buildout, you can use buildout's facilities for >fixing versions. > >For individual reusable "library packages", you want to make the >dependencies as non-restrictive as possible so as to maximize >flexibility and reusability. I agree but not to specify a minimal version and instead to assume that always the latest release version must be used does not maximize but reduce reusablitity. Look at the following szenario: In a given system module "A" is installed in version "M.m". For some reason, another module "B" in the system cannot work with "A" in any version "M.m'" with "m' > m". I know that this violates your assumption that any newer minor release is compatible with any older one (in the same major release). Unfortunately, such things happen Now assume we want to install module "C" which needs "A" in version "M.*". If "M.*" implicitly means: the newest minor release in the "M" series, then "C" cannot be installed in the hypothetical system. If, on the other hand, the dependency is expressed by "A >=M.m, <= M.", then "C" can be installed. If your suppositions are only a form of introduction for the "M.*" syntax (or "M*", if you prefer) but does not affect the semantics of "M.*", i.e. if "M.*" means 'needs the module in *any* "M" version', then I have no objections. Even for me "M.*" is nicer than "M.9". -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
--On 31. Mai 2007 20:08:02 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote: Jim Fulton wrote at 2007-5-31 10:12 -0400: In thinking about how we might specify that we want to depend on major versions but sometimes need to specify minimum versions, the following occurred to me: - Suppose that we always had access to the latest released version, - Suppose that, within a major release, all releases were backward compatible, Then I assert that there is no *need* to specify a minimum release within a major release. I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. That's why one should have enough tests...although tests will never cover all cases. -aj pgpt1WGkPLSoR.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
On May 31, 2007, at 2:08 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-5-31 10:12 -0400: In thinking about how we might specify that we want to depend on major versions but sometimes need to specify minimum versions, the following occurred to me: - Suppose that we always had access to the latest released version, - Suppose that, within a major release, all releases were backward compatible, Then I assert that there is no *need* to specify a minimum release within a major release. I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. I agree, but this control should occur at at a different place. I suggest that when deploying or releasing an application or system, you want to fix all of the versions so that a released or deployed configuration is repeatable and so that changes are introduced in a controlled way. This can be done in a number of ways. You can have an application meta-package that specifies all of the versions, or, if you are using buildout, you can use buildout's facilities for fixing versions. For individual reusable "library packages", you want to make the dependencies as non-restrictive as possible so as to maximize flexibility and reusability. 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] A thought on backward compatibility and minimum versions
On 31.05.2007, at 20:08, Dieter Maurer wrote: I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. i think we are talking about package dependencies here, and not application dependencies if an egg based application e.g zope 3.5 is released, the package versions should be nailed down anyways by buildouts "version" section and packages should be more tolerant, so that changes of version conflicts gets minimized when collecting them in an application ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
Jim Fulton wrote at 2007-5-31 10:12 -0400: > >In thinking about how we might specify that we want to depend on >major versions but sometimes need to specify minimum versions, the >following occurred to me: > >- Suppose that we always had access to the latest released version, > >- Suppose that, within a major release, all releases were backward >compatible, > >Then I assert that there is no *need* to specify a minimum release >within a major release. I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
Am Donnerstag, den 31.05.2007, 11:12 -0400 schrieb Jim Fulton: > On May 31, 2007, at 11:09 AM, Christian Theune wrote: > > > Hi, > > > > Am Donnerstag, den 31.05.2007, 10:56 -0400 schrieb Jim Fulton: > >>> Would a requirement of "foobar 2.1*" mean every stable release of > >>> "foobar 2.1" and all micro versions? > >> > >> I don't understand your question. > > > > The intention was to find out whether your proposed schema only > > applies > > to the major versions or all version components. > > Any version. So: "foo 2.3.4" is equivalent to: "foo >=2.3.4, > <2.3.4.9". Ok, thanks for the clarification. -- 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
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
On May 31, 2007, at 11:09 AM, Christian Theune wrote: Hi, Am Donnerstag, den 31.05.2007, 10:56 -0400 schrieb Jim Fulton: Would a requirement of "foobar 2.1*" mean every stable release of "foobar 2.1" and all micro versions? I don't understand your question. The intention was to find out whether your proposed schema only applies to the major versions or all version components. Any version. So: "foo 2.3.4" is equivalent to: "foo >=2.3.4, <2.3.4.9". 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] A thought on backward compatibility and minimum versions
Hi, Am Donnerstag, den 31.05.2007, 10:56 -0400 schrieb Jim Fulton: > > Would a requirement of "foobar 2.1*" mean every stable release of > > "foobar 2.1" and all micro versions? > > I don't understand your question. The intention was to find out whether your proposed schema only applies to the major versions or all version components. > BTW, I intend to propose allowing versions to be used without *s. Ah, fine too, I guess. 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
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
On May 31, 2007, at 10:51 AM, Christian Theune wrote: Ah, Am Donnerstag, den 31.05.2007, 10:12 -0400 schrieb Jim Fulton: In thinking about how we might specify that we want to depend on major versions but sometimes need to specify minimum versions, the following occurred to me: [...] Ah, I think it's a good idea. And it would still allow us to handle restrictions when authors don't handle their project management like we do. Would a requirement of "foobar 2.1*" mean every stable release of "foobar 2.1" and all micro versions? I don't understand your question. BTW, I intend to propose allowing versions to be used without *s. 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] A thought on backward compatibility and minimum versions
Ah, Am Donnerstag, den 31.05.2007, 10:12 -0400 schrieb Jim Fulton: > In thinking about how we might specify that we want to depend on > major versions but sometimes need to specify minimum versions, the > following occurred to me: > [...] Ah, I think it's a good idea. And it would still allow us to handle restrictions when authors don't handle their project management like we do. Would a requirement of "foobar 2.1*" mean every stable release of "foobar 2.1" and all micro versions? 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
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
On Thursday 31 May 2007 10:25, Benji York wrote: > Jim Fulton wrote: > > In thinking about how we might specify that we want to depend on > > major versions but sometimes need to specify minimum versions, the > > following occurred to me: > > I really like it. Of course we can do it without new syntax (unless I'm > missing something), but the syntax would help a lot in making the intent > clear. > > +1 I really like it too and the reasoning sounds good to me. +1 Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
Jim Fulton wrote: In thinking about how we might specify that we want to depend on major versions but sometimes need to specify minimum versions, the following occurred to me: I really like it. Of course we can do it without new syntax (unless I'm missing something), but the syntax would help a lot in making the intent clear. +1 -- 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
[Zope3-dev] A thought on backward compatibility and minimum versions
In thinking about how we might specify that we want to depend on major versions but sometimes need to specify minimum versions, the following occurred to me: - Suppose that we always had access to the latest released version, - Suppose that, within a major release, all releases were backward compatible, Then I assert that there is no *need* to specify a minimum release within a major release. Consider an example: I depend on foo 2 (foo >=2 <2.999). Now foo 2.5 introduces a new feature and I use this feature. In reality, I now depend on version 2.5 or higher (and <2.999). I shouldn't need to specify this. After all, I'll always get new releases. Why wouldn't I? Well, I might also depend on bar and bar might depend on foo <=2.4. Why would bar do this? The only sane reason is that 2.5 introduced a backward- incompatible change, but we don't allow that. If we don't have to worry about backward incompatible changes within a major release cycle, then there is no reason to set an upper limit and therefore, there is no *practical* need to specify a lower limit. Combined with the fact that that great majority of packages don't change very much after they have become stable, I think most package dependencies could be expressed very simply if there was a simple syntax to specify *just* the major version. In the context of setuptools, I think "*" could be used, as has been suggested, but without leading =s. So, to specify foo version 2, I think the following syntax would be very reasonable: foo 2* This wouldn't prevent someone from specifying a minimum version. For example, to combine this with a minimum requirement of 2.5: foo 2* >=2.5 If people like these ideas, I'd be willing to lobby for them on the distutils sig, especially if I have help. :) Note that the proposal would be that, a specification of the form if a version number followed by a * would be equivalent to a range: "project_name V*" is equivalent project_name "V.*" is equivalent to "project_name >=V (Or maybe equivalent to "project_name >=V.dev <=V.9".) Also note that It's not clear that the * is needed. "foo 2" isn't a valid specification. We *could* extend the requirements language to allow a project name followed by a version number. So: "prject_name V" is equivalent to "project_name >=V 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
