Documentation for 3rd party Products how to upgrade for Plone 4?

[Patrick Gerken]

Hi,

is there any place to track what 3rd Party developers need to change
to get ready for Plone 4?

I have done it just for fun for borg.project, and these were my findings:

- buildout.cfg changes a lot, since I can now simply use the zope2 egg.
- Interfaces of zope.app.container moved to zope.container. All
references were in zcml code,
  I have now two registrations for my browser. I use zcml:condition
here: 'zcml:condition="installed zope.app.container"'
- A DocTest is messing with internal object creation. Who does this
kind of things, knows what he is doing and knows how to fix it.

All in all I consider it pretty painless but borg.project does not
have a lot of code.

Also, there is probably no package that does not use
zope.app.container interfaces. So virtually all Products have to be
upgraded for Plone4.

So, back to my question, is there anything already?
If not, can anybody contribute his experiences too, I could then
generate a document about it and give an open space at the Plone
Conference, together with how to test compatibility automatically with
buildbot.

Best regards,

       Patrick

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

Hi.

On Tue, Oct 13, 2009 at 10:52 AM, Patrick Gerken
<[hidden email]> wrote:
> is there any place to track what 3rd Party developers need to change
> to get ready for Plone 4?

The closest we have was done by David and currently lives in SVN at
https://svn.plone.org/svn/plone/Plone/branches/4.0/docs/BACKWARDS_COMPATIBILITY.txt

This should be moved into a new section at
http://plone.org/documentation/manual/upgrade-guide.

> I have done it just for fun for borg.project, and these were my findings:

Awesome, thanks for doing that. We'll probably still see some more
changes once all the other PLIP's are merged.

> - buildout.cfg changes a lot, since I can now simply use the zope2 egg.

Yep. This will change some more once we get mandatory blobs into the mix.

> - Interfaces of zope.app.container moved to zope.container. All
> references were in zcml code,
>  I have now two registrations for my browser. I use zcml:condition
> here: 'zcml:condition="installed zope.app.container"'

The other backwards compatible approach is to explicitly declare that
you depend on zope.app.container in your setup.py. There's backwards
compatibility imports in the latest version of that package. It just
so happens that Plone/Zope2 itself no longer depends on this one.

> - A DocTest is messing with internal object creation. Who does this
> kind of things, knows what he is doing and knows how to fix it.
>
> All in all I consider it pretty painless but borg.project does not
> have a lot of code.

Sounds good.

> Also, there is probably no package that does not use
> zope.app.container interfaces. So virtually all Products have to be
> upgraded for Plone4.

I kind of expect every package to need some form of minor adjustments
to work with Plone 4.

> So, back to my question, is there anything already?
> If not, can anybody contribute his experiences too, I could then
> generate a document about it and give an open space at the Plone
> Conference, together with how to test compatibility automatically with
> buildbot.

See above for the started docs. I know Andreas Zeidler (witsch) added
buildout configurations to plone.app.blob to test it across Plone
versions. Maybe there's something to look at or encourage.

Hanno

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Patrick Gerken wrote:

> Hi,
>
> is there any place to track what 3rd Party developers need to change
> to get ready for Plone 4?
>
> I have done it just for fun for borg.project, and these were my findings:
>
> - buildout.cfg changes a lot, since I can now simply use the zope2 egg.
> - Interfaces of zope.app.container moved to zope.container. All
> references were in zcml code,
>   I have now two registrations for my browser. I use zcml:condition
> here: 'zcml:condition="installed zope.app.container"'
> - A DocTest is messing with internal object creation. Who does this
> kind of things, knows what he is doing and knows how to fix it.
>
> All in all I consider it pretty painless but borg.project does not
> have a lot of code.
>
> Also, there is probably no package that does not use
> zope.app.container interfaces. So virtually all Products have to be
> upgraded for Plone4.

I thought there were BBB aliase in zope.app.container, so those
references should still work. If not, that's bad (and possibly a Zope bug).

You may need to depend on zope.app.container though, if it's not pulled
in by default.

> So, back to my question, is there anything already?
> If not, can anybody contribute his experiences too, I could then
> generate a document about it and give an open space at the Plone
> Conference, together with how to test compatibility automatically with
> buildbot.

We definitely should start an upgrade manual like we had for 3.x.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[JonStahl]

On Tue, Oct 13, 2009 at 2:46 AM, Hanno Schlichting <[hidden email]> wrote:

> On Tue, Oct 13, 2009 at 10:52 AM, Patrick Gerken
> <[hidden email]> wrote:

>> Also, there is probably no package that does not use
>> zope.app.container interfaces. So virtually all Products have to be
>> upgraded for Plone4.
>
> I kind of expect every package to need some form of minor adjustments
> to work with Plone 4.

If this is the case, then we probably need to do a hard-core push on
product upgrades BEFORE Plone 4 launch, in order to avoid the
first-day-of-release product breakage that is the worst possible
advertisement for a Plone upgrade.  I think the Plone 3 experience
shows that we can't rely on product authors rallying without some
serious prodding.  (They're all busy people and many of them arent'
following the core dev process that closely!)

I recommend the following (straw man for discussion):

1) Get a solid product upgrade guide published ASAP (already in
progress, I know, thanks davisagli, et al!)

2) Harvest all product author emails from Plone.org, blast out a
series of emails pointing them to the upgrade guide and urging them to
make these fixes before the Plone 4 launch date.  (Possibly limit this
to products flagged as Plone 3-compatible.)

3) Identify a list of "must-have products" (e.g things of the
magnitude of PFG, LinguaPlone, etc.), create Trac tickets and close
them out in order to monitor progress.  (Possibly a custom Trac
report, too, which can be part of our upgrade docs, e.g. "Products
known to be updated!")

4) Organize a team to make proactive checkins if authors of "must-have
products" don't respond promptly, similar to the "egg-a-geddon" work
that Alex Clark and others did.

:jon

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Ross Patterson-2]

Jon Stahl <[hidden email]> writes:

> On Tue, Oct 13, 2009 at 2:46 AM, Hanno Schlichting <[hidden email]> wrote:
>
>> On Tue, Oct 13, 2009 at 10:52 AM, Patrick Gerken
>> <[hidden email]> wrote:
>
>>> Also, there is probably no package that does not use
>>> zope.app.container interfaces. So virtually all Products have to be
>>> upgraded for Plone4.
>>
>> I kind of expect every package to need some form of minor adjustments
>> to work with Plone 4.
>
> If this is the case, then we probably need to do a hard-core push on
> product upgrades BEFORE Plone 4 launch, in order to avoid the
> first-day-of-release product breakage that is the worst possible
> advertisement for a Plone upgrade.  I think the Plone 3 experience
> shows that we can't rely on product authors rallying without some
> serious prodding.  (They're all busy people and many of them arent'
> following the core dev process that closely!)
>
> I recommend the following (straw man for discussion):
>
> 1) Get a solid product upgrade guide published ASAP (already in
> progress, I know, thanks davisagli, et al!)
>
> 2) Harvest all product author emails from Plone.org, blast out a
> series of emails pointing them to the upgrade guide and urging them to
> make these fixes before the Plone 4 launch date.  (Possibly limit this
> to products flagged as Plone 3-compatible.)
>
> 3) Identify a list of "must-have products" (e.g things of the
> magnitude of PFG, LinguaPlone, etc.), create Trac tickets and close
> them out in order to monitor progress.  (Possibly a custom Trac
> report, too, which can be part of our upgrade docs, e.g. "Products
> known to be updated!")
>
> 4) Organize a team to make proactive checkins if authors of "must-have
> products" don't respond promptly, similar to the "egg-a-geddon" work
> that Alex Clark and others did.

+10

I think this approach, particularly #3, also become a fulcrum of
embarrassment in the larger add-on ecosystem to help speed upgrades.

Ross


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Maurits van Rees-3]

Martin Aspeli, on 2009-10-13:

> Patrick Gerken wrote:
>> Hi,
>>
>> is there any place to track what 3rd Party developers need to change
>> to get ready for Plone 4?
>>
>> I have done it just for fun for borg.project, and these were my findings:
>>
>> - buildout.cfg changes a lot, since I can now simply use the zope2 egg.
>> - Interfaces of zope.app.container moved to zope.container. All
>> references were in zcml code,
>>   I have now two registrations for my browser. I use zcml:condition
>> here: 'zcml:condition="installed zope.app.container"'
>> - A DocTest is messing with internal object creation. Who does this
>> kind of things, knows what he is doing and knows how to fix it.
>>
>> All in all I consider it pretty painless but borg.project does not
>> have a lot of code.
>>
>> Also, there is probably no package that does not use
>> zope.app.container interfaces. So virtually all Products have to be
>> upgraded for Plone4.
>
> I thought there were BBB aliase in zope.app.container, so those
> references should still work. If not, that's bad (and possibly a Zope bug).
>
> You may need to depend on zope.app.container though, if it's not pulled
> in by default.
>
>> So, back to my question, is there anything already?
>> If not, can anybody contribute his experiences too, I could then
>> generate a document about it and give an open space at the Plone
>> Conference, together with how to test compatibility automatically with
>> buildbot.
>
> We definitely should start an upgrade manual like we had for 3.x.
>
> Martin
>

A long time ago (maybe last year?) I created a document in the upgrade
guide on plone.org about the removal of global defines.  It is still
in the draft state.  Hm, I expected there to be a transition to
'pending review' or something, but I can only publish it.  And in the
draft state anonymous has no view permisison.  Oh well, I published it:

http://bit.ly/BFoiY

Okay, same is true for the parent folders, so I published those too.  See

http://plone.org/documentation/manual/upgrade-guide/version/upgrading-plone-3-x-to-4.0

Please improve. :-)

--
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Tue, Oct 13, 2009 at 4:54 PM, Jon Stahl <[hidden email]> wrote:
> 3) Identify a list of "must-have products" (e.g things of the
> magnitude of PFG, LinguaPlone, etc.), create Trac tickets and close
> them out in order to monitor progress.

I stepped forward inside Jarn to make sure we will upgrade all the
packages we've released and feel some sort of ownership for Plone 4.0.
We'll setup nightly test runs for all of them for both Plone 3.3 and
4.0. I hope we can contribute to documentation and report about the
experience we make while doing so.

I hope this will cover some of the common add-ons and encourage other
people to do the same. We just started on organizing this, and it'll
take us some time to get this moving.

Hanno

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Patrick Gerken]

On Tue, Oct 13, 2009 at 13:45, Martin Aspeli <[hidden email]> wrote:
> I thought there were BBB aliase in zope.app.container, so those
> references should still work. If not, that's bad (and possibly a Zope bug).

I consider this a zope bug too, but Tres Seavers believes its the
third party fault if they don't declare dependencies cleanly. I tend
to disagree in this certain case.
One solution could be to add zope.app.container as a dependency to
Plone 4.0 and remove that dependency on 4.1.
I assume that everybody is using buildout these days to build Plone4
and we might state in the changes of Plone 4.1. that some products
might produce breakages because they haven't really been updated yet
and that in the case of a missing zope.app.container package, two
things a necessary: 1. Make the faulty package Plone 4 compatible or
bribe the maintainers with money, pizza, prayers for their well being
to make the package compatible, 2. Until then, add zope.app.container
as an egg.

Adding the dependency in Plone 4.0, because we want to make the
upgrade as smooth as possible.
Removing it in 4.1. because it would probably the only breakage, be
small in its effort to fix, and hopefully everybody fixed his product
already.

Best regards,

    Patrick

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Tue, Oct 13, 2009 at 10:12 PM, Patrick Gerken
<[hidden email]> wrote:
> One solution could be to add zope.app.container as a dependency to
> Plone 4.0 and remove that dependency on 4.1.

This will not only apply to zope.app.container but all zope.* and
zope.app.* packages people might have been using, but which aren't
dependencies of Plone anymore. We are talking about at least 60
packages here. I don't see any way to make a clear distinction between
more wildly used and less wildly used packages of these.

If we ever want to reduce our codebase and reduce complexity, we will
need to stop shipping these kinds of packages at some point. I'd only
be comfortable to do this in a major x.0 release like 4.0 or 5.0.

Should we not do this for Plone 4.0 we will have the same kind of
situation for Plone 5.0 again. As the Zope community stopped using the
zope.deprecation system, there's no notification about using an old
package. The only way people will know and do something about these
changes is with a clear cut ImportError.

I'd be highly in favor of making sure we demand packages to declare
their real dependencies for Plone 4.0. This is fully backwards
compatible with Plone 3.

Hanno

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Hi Patrick,

> On Tue, Oct 13, 2009 at 13:45, Martin Aspeli <[hidden email]> wrote:
>> I thought there were BBB aliase in zope.app.container, so those
>> references should still work. If not, that's bad (and possibly a Zope bug).
>
> I consider this a zope bug too, but Tres Seavers believes its the
> third party fault if they don't declare dependencies cleanly. I tend
> to disagree in this certain case.

Actually, I agree with Tres.I thought that there was a z.a.container
but it didn't have the interfaces anymore.

The solution is simple: add the dependency. Note that you don't have
to add it in the product, you could also just add it in buildout.cfg.

> One solution could be to add zope.app.container as a dependency to
> Plone 4.0 and remove that dependency on 4.1.

-1

What I think we should do is maintain a version for z.a.container in
the KGS indefinitely so that when people *do* depend on it, they get a
sane version.

We need to start having fewer dependencies. If it's there, people will
get confused and use it. We've had eggs since Plone 3.2 and it's not
unreasonable to expect people to declare their dependencies, so long
as there's an "integrator's workaround" of just shoving them into
buildout.cfg.

> I assume that everybody is using buildout these days to build Plone4
> and we might state in the changes of Plone 4.1. that some products
> might produce breakages because they haven't really been updated yet
> and that in the case of a missing zope.app.container package, two
> things a necessary: 1. Make the faulty package Plone 4 compatible or
> bribe the maintainers with money, pizza, prayers for their well being
> to make the package compatible, 2. Until then, add zope.app.container
> as an egg.

Right. We definitely need to document this carefully. We did for the
Plone 2.5 -> 3 upgrade guide. We need the same for Plone 4.

> Adding the dependency in Plone 4.0, because we want to make the
> upgrade as smooth as possible.

Except it goes against our goal of shedding code cruft. We can't shed
this in 4.1 because we can't break things in minor releases.

> Removing it in 4.1. because it would probably the only breakage, be
> small in its effort to fix, and hopefully everybody fixed his product
> already.

I see your point, but I think it's better to ask people to depend on
it or else add it to their buildouts.

It's not *that* common a dependency that it'll break absolutely everything. :)

Martin

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Wed, Oct 14, 2009 at 3:41 AM, Martin Aspeli <[hidden email]> wrote:
> What I think we should do is maintain a version for z.a.container in
> the KGS indefinitely so that when people *do* depend on it, they get a
> sane version.

We will depend in some way on the official 2.12 KGS from
http://download.zope.org/Zope2/index/2.12.0/versions.cfg. This still
includes a compatible z.a.container version (3.8.0).

But Zope 2.13 depends on the Zope Toolkit KGS, which by the time of
its release is no longer going to contain version pins for old
packages like zope.app.container. These packages won't be maintained
anymore by the Zope community at large and I don't expect them to keep
working any longer with the ever refactored set of ZTK packages. While
we use Zope 2.12 we can still offer some reasonable stability for
these old packages. But we need to make sure people move off these
packages soon enough.

Hanno

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers