[Glass] Instances of obsolete classes after stone upgrade

[Dale Henrichs]

>
> Check.
> To be clear: it’s not in the post upgrade step of the GsDevKit code?
> It’s not that I missed it when copying them to our scripts…?
>
The session method cleanup script I sent is NOT part of postUpgrade
processing ...  I didn't think that the session methods structure could be
a culprit for holding onto old GsMethod instances until you noticed the
problem, so I've submitted an issue against GsDevKit_upgrade[1] which is
used to drive the seasideImage upgrade process for 3.5.x and beyond ...

Dale

[1] https://github.com/GsDevKit/GsDevKit_upgrade/issues/21

On Fri, Nov 19, 2021 at 12:40 PM Johan Brichau <johan at yesplan.be> wrote:

>
>
> > On 19 Nov 2021, at 21:07, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
> >
> > With regards to dealing with block instances, I believe there should be
> a section in the release notes that provides scripts for finding a
> replacing obsolete block instances for use cases like SortedCollection,
> where the potentially obsolete block instance is stored in an instance
> variable ...
>
> Yes, we apply the postconv script as mentioned in the upgrade instructions.
> We have some blocks left in our application code that require manual
> intervention and that’s why we also noticed the ones referenced by the
> GsMethod instances.
>
> > And yes, the session method cleanup code should be included in your post
> upgradeSeasideImage processing along with "sort block" cleanup code ...
>
> Check.
> To be clear: it’s not in the post upgrade step of the GsDevKit code?
> It’s not that I missed it when copying them to our scripts…?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20211119/da4f08ba/attachment.htm>