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

[Martijn Faassen]

Steve Schmechel wrote:
> 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?

We're talking about a very specific case: a package that pulls in 
dependencies that have been lost in the upgrade.

We know we can handle that case very simply, and we know that case is 
coming up. I therefore propose we handle it.

You're asking about the general case, so I'll talk a little bit about my 
philosophy about that.

In general we'll have to treat backwards compatibility on a case by case 
basis. Making it easier for people to upgrade and test their code for 
Grok 1.1 does not automatically mean we'll make it easier for Grok 2.0 
or whatever. That we will need to figure out.

Note that I'm also not proposing we support this particular form of 
backwards compatibility forever. The goal is our dependency of many 
zope.app.* packages altogether, and at some point those packages won't 
be compatible with modern Grok releases anymore.

In general we want to move forward. This sometimes requires us breaking 
old code. A good way to break this in a nice way is:

* a release with the old way

* a release that supports the new way but also still the old way, 
perhaps with some extra work for the developer. This release helps the 
user to migrate away code from the old way to the new way.

* a release that only supports the new way.

Of course this isn't always possible, but it's at least a pattern we 
should look to support. It's also possible however that at some point we 
want to make changes big or complex enough that this isn't possible. 
We'll need to weigh the cost and benefit each time.

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

I agree that we're only supporting this stuff for a very specific 
reason. Perhaps we want to call it 'grok-backwards-dependencies' or 
something to make that even more clear. We should also clearly say in 
its release notes what it's for, for each release:

1.1
---

* This package pulls in dependencies that were
   there in Grok 1.0 but are not there anymore in Grok 1.1. The developer
   can install this package to ensure that those dependencies are also
   there in Grok 1.1, so that he can upgrade code from Grok 1.0 to Grok
   1.1. This version only supports Grok 1.1.x, and does not support
   future versions of Grok beyond Grok 1.1.x.

Once we have Grok 1.2, we could have a release 1.2 for it that supports 
the transition from 1.1 to 1.2 (which is when this package will become a 
lot more relevant).

Regards,

Martijn