Tres Seaver wrote:

I'd say leave the extra shim in place for the time being. We can then 
see about getting rid of that at some point.

> In any package where I create a backward incompatibility, I will
> certainly document it clearly, with instructions on how to update
> dependent packages.  Putting the canonical docs in the package is an
> absolute necessity for reuse of the package outside any larger package
> set, anyway.

Agreed about that.

Concerning a master list of changes. Let's ignore the concept of 
lockstep releases for the time being in this discussion. We can easily 
decouple this from the discussion about a list of major changes to 
various zope packages.

I'd still like there to be a master list marks big changes that people 
need to be aware of when they upgrade their packages to newer versions. 
If they're going to make their own package lists, they can get an 
overview of what to watch out for. And us people who maintain lists of 
such packages that get release numbers can also look out for those.

This isn't a list by version but just a list maintained by date, or per 

Now that I think about it, we can turn it around and aggregate the 
existing CHANGES.txt as news somehow. Perhaps some way to turn them into 
Atom feeds; a script would then be simple enough to write to aggregate 
all non-bugfix releases.



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to