[Grok-dev] dependencies missing needed for Grok 1.1 backwards compatibility

[Sebastian Ware]

It would seem reasonable to drop such backward compatibility at major  
releases. The issue is really about minor releases. Also, if you look  
at Zope 2, there are a lot of people who invest time in maintaining  
backwards compatibility.

Mvh Sebastian

24 mar 2010 kl. 16.33 skrev Steve Schmechel:

> It sounds great and it certainly helps short-term, but how does it
> affect Grok long-term?  What about Grok versions 1.3, 1.4. 1.5, 2.0,
> 2.1, 2.3, 3.0, and 3.1?  Do backward compatibility packages get  
> written
> for each one?  Will they work for all the possible upgrade paths?
>
> What about the poor developer who wants to upgrade from 1.0 to 1.4  
> while
> developers are busy working on the final touches for the version 3.0
> release?  Something doesn't work and he blames the "grok-backwards"  
> code
> and files a bug report.  Who is going to want to work on that?
>
> Going back and reading all the release notes and working through his  
> own
> code is probably the right solution.  Using on a broken list of  
> packages
> and a bunch of console error statements to debug will probably be much
> harder.
>
> Maybe, we can put some disclaimers on the Grok-backwards packages
> stating a limited scope and lifetime.  The future is hard to predict  
> and
> this stuff is bound to get messy.
>
>
> --- On Wed, 3/24/10, Simon Jagoe <simon.jagoe at pragmagility.com> wrote:
>
>> From: Simon Jagoe <simon.jagoe at pragmagility.com>
>> Subject: Re: [Grok-dev] dependencies missing needed for Grok 1.1  
>> backwards compatibility
>> To: "Martijn Faassen" <faassen at startifact.com>
>> Cc: grok-dev at zope.org
>> Date: Wednesday, March 24, 2010, 9:26 AM
>> Hi all,
>>
>> I think Martijn's proposal is a good idea. It also allows
>> you to
>> be able to run your unit tests while you are removing
>> these
>> dropped imports. Without something like this you either
>> need
>> to (1) manually add all the dependencies yourself (from a
>> list in
>> the release notes) or (2) fix all of the imports before you
>> can
>> run tests.
>>
>> In the case of (1), the Grok developers need to produce a
>> list to
>> place in the release notes anyway, so there is not much
>> more to
>> placing them in a setup.py, as Martijn says.
>>
>> In the case of (2), the application developer has to put in
>> more
>> effort to determine if a new error in the application is
>> caused
>> by the new version of Grok or if it is an error in
>> upgrading the
>> application to use the new version of Grok. With unit
>> tests
>> running continuously, it is a lot easier to ensure that
>> the
>> correct dependencies are removed and no regressions are
>> introduces at the same time.
>>
>> Regards,
>> Simon
>>
>> ----- Original Message -----
>> From: "Martijn Faassen" <faassen at startifact.com>
>> To: grok-dev at zope.org
>> Sent: Wednesday, March 24, 2010 2:16:55 PM GMT +00:00 GMT
>> Britain, Ireland, Portugal
>> Subject: Re: [Grok-dev] dependencies missing needed for
>> Grok 1.1 backwards compatibility
>>
>> Hi there,
>>
>> I think people misunderstood my proposal. I'm not talking
>> about a
>> complicated backwards compatibility package. I'm talking
>> about something
>> very simple.
>>
>> I'm talking about the situation we face with Grok 1.1:
>>
>> Grok 1.1 doesn't include zope.app.catalog anymore in its
>> dependencies.
>> It's not being pulled in anymore. Quite possibly other
>> packages are not
>> pulled in anymore either that were pulled in by Grok 1.0
>> code.
>>
>> A project that *uses* Grok 1.0 will quite possibly import
>> from
>> zope.app.catalog directly however. And other places.
>>
>> If I have this situation, I can read upgrade notes
>> (handwave them into
>> existence like everybody else in this thread) and expand my
>> setup.py to
>> include the list of packages that's now been retired.
>>
>> Alternatively, I can read the upgrade notes and just expand
>> my setup.py
>> to include the grok-backwards package, version 1.1. It
>> depends on
>> zope.app.catalog and the rest. It doesn't do anything
>> else.
>>
>> For Grok 1.1 this isn't so important yet, as concretely we
>> are not able
>> to drop many packages yet.
>>
>> My hope is that for Grok 1.2, we'll be able to drop a *lot*
>> of packages.
>>   Instead of maintaining a list in some documentation
>> somewhere, we
>> instead maintain the list in code, which is easier to test
>> and easier to
>> instruct people to use. So for Grok 1.2 grok-backwards will
>> become very
>> relevant, as hopefully the list of dropped packages is
>> long.
>>
>> Of course the goal is for people to adjust their code so
>> they don't need
>> grok-backwards anymore. But helping people to upgrade is
>> something we
>> need to do anyway.
>>
>> Regards,
>>
>> Martijn
>>
>>
>> _______________________________________________
>> Grok-dev mailing list
>> Grok-dev at zope.org
>> https://mail.zope.org/mailman/listinfo/grok-dev
>> _______________________________________________
>> Grok-dev mailing list
>> Grok-dev at zope.org
>> https://mail.zope.org/mailman/listinfo/grok-dev
>>
>
>
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev