Hi folks.  I'm working on a ZPatterns 0.4.2b1 release for the early part of
the coming week, and intend to bug Ty into perhaps releasing an 0.9.0 beta
later in the week.  However, these versions are likely to have some
(hopefully minor) compatibility issues with previous releases.  Specifically:

* We would like to drop support for Zope 2.1.x from here on out.  I know at
least one user has a production 2.1.x system, and I hate to strand them,
but at least they can continue to use existing ZPatterns releases until
their client can upgrade.  Dropping 2.1.x support means that we may be able
to get rid of DynPersist, which should be a big plus for ease of
installation.  It also means that we'll be able to start adding newer
capabilities that take advantage of 2.2.x-isms such as
getPhysicalPath()/restrictedTraverse(), etc.

* We would like to drop support for Specialists directly containing data
plug-ins.  This feature was intended to allow for acquiring shared data
plug-ins from within Racks, so that common attribute or sheet providers
could be shared among Racks without copying.  In practice, Ty and I have
never once used this capability, and it could be easily replaced with the
ability to "include" a SkinScript within another SkinScript, if we take
advantage of 2.2.x-isms.

* Related to the above, the "Link to Acquired Provider" and "Acquired ...
Provider" objects would no longer be needed, since they exist only to make
use of shared plug-ins contained in Specialists.  We would remove these
classes from ZPatterns, causing any existing instances to become "broken".
Deleting these "broken" objects, however, would restore normal operations
of the system.

As you can see, all of these issues are somewhat interrelated.  I wanted to
post some advance warning of all this, so that if anyone has any
objections, they would have a last chance to protest.  :)

The overall release plan at this point is that the only other major
features planned in the 0.4.x series are content providers (mirroring
virtual sub-objects from SQL, LDAP, or whatever) and local role providers
(computation by an object of local roles applicable to a user).  I do
expect to add a few minor features in the way of easier SkinScript editing,
and some hooks to allow help to be added to the management tabs which are
auto-generated for PlugInGroups.  The next big project will be
documentation, now that the feature set and terminology is beginning to
stabilize.


_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to