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 - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -