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

[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
>