Handling of deprecation packages

Hi,

in the past after each release iteration one of the first things applied to a new development image
 - was to remove the "DeprecatedXX" package of the previous version XX
 - and add a new "DeprecatedYY" package for the new pharo version YY

This allowed then to mark classes that should get obsolete for version YY and put them into "DeprecatedYY"

But in current Pharo 8 dev image we still have the "Deprecated70" package inside and a new "Deprecated80"
is not yet opened.

I know there
 - were some discussion about having a "migrator" tool first to help in the transition to the new release
   (but I guess this "migrator" could be written using P7 image, no?)

 - we can also not just delete "Deprecated70" as StandardFileStream, MultiByteFileStream and others are
   still useds in the code without giving a proper

So I wonder what is the status and on plan this in P8

Thx
T.

Hi torsten

I do not remember if I migrated deprecated70 to the migrator package.
I should check but if someone else wants to have a look even better.
Then my thought was that the streams are important and making the live of people easier to migrate
important too especially since we cannot fully automate Stream deprecation.

Now I would like to understand why this is so a problem for you?

Stef

Hi Stef,

It's not a big problem. I primary wanted to ask what is the status and overall plan.

The problem with the new vs. old streams seems to be that migration is unfinished even for the base image.
Development already switched quickly to newer construction sites instead of finishing these old ones.
That does not mean that I do not appreciate the new journeys Pharo 8 will bring - but it still gives this
bad feeling of important transitions are incomplete and should have been addressed first.

That's why also "Deprecated70" could not easily get removed. And there is no guide in how to migrate to the new stream.
At least I do not know of something that could quickly explain on how to convert.

If we integrate a "Deprecated80" (which I think we should do to continue deprecating stuff like required
for issue #3186) it could easily lead to confusion when we have two deprecated packages.

For "Deprecated70" and "Deprecated80" it might be clear from the name but as for P7 there were also
deprecations for other packages like "Ring-Deprecated*" it might not be clear over time when and how
they were deprecated.

The previous scheme we used to directly remove old deprecations when a new Pharo release iteration started
was at least more clear and I think it helped people to better sort out what and when to stop using stuff.

Bye
T.

> Hi Stef,
>
> It's not a big problem. I primary wanted to ask what is the status and overall plan.
>
> The problem with the new vs. old streams seems to be that migration is unfinished even for the base image.

If you find some let us know.
The objective is to be able to remove the old stream packages and I thought that we were there.

> Development already switched quickly to newer construction sites instead of finishing these old ones.

Not really, we are mainly making sure that
        - Schmidt is able to work on their migration (it means be able to use Spec2)
        - Improving Windows support as well as speed problems as for Lifeware.

> That does not mean that I do not appreciate the new journeys Pharo 8 will bring - but it still gives this
> bad feeling of important transitions are incomplete and should have been addressed first.

We do not share this completely but I understand your point.
Now given the state of the old streams I think that guille did a ***massive*** amount of work.

> That's why also "Deprecated70" could not easily get removed. And there is no guide in how to migrate to the new stream.

Did you check the comments of Stream?

> At least I do not know of something that could quickly explain on how to convert.

The problem is that with the old stream you could change in the middle from binary to text and vice versa
in an insane way.

> If we integrate a "Deprecated80" (which I think we should do to continue deprecating stuff like required
> for issue #3186) it could easily lead to confusion when we have two deprecated packages.

Sure go ahead and propose a new package.

> For "Deprecated70" and "Deprecated80" it might be clear from the name but as for P7 there were also
> deprecations for other packages like "Ring-Deprecated*" it might not be clear over time when and how
> they were deprecated.

Yes we should really remove Ring and for this one this is unfinished.

> The previous scheme we used to directly remove old deprecations when a new Pharo release iteration started
> was at least more clear and I think it helped people to better sort out what and when to stop using stuff.

Did you try to remove the old streams and got problems?
Because this is something that we should try.


S.

I’m away from computers and digging a pond in my garden.
Will back to Pharo next week.

Torsten Bergmann <[hidden email]> wrote:
> The problem with the new vs. old streams seems to be that migration is
> unfinished even for the base image.
> Development already switched quickly to newer construction sites instead
> of finishing these old ones.

There are indeed several open issues with the new streams usage. I posted
one on the handling of filing in fileouts by drag and drop.

The issue I see with existing code is mostly that an object is used as a
stream but is actually an information holder which understands much more
than the stream protocol. Rewriting that code to use a streamHolder can be
non-trivial.

The fallback behavior of a readWriteStream opened on a read-only file is
also not easy to get right.

Stephan