> 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.
>
> Bye
> T.
>
>
>> Gesendet: Donnerstag, 18. April 2019 um 08:26 Uhr
>> Von: "ducasse" <steph...@netcourrier.com>
>> An: "Pharo Development List" <pharo-dev@lists.pharo.org>
>> Betreff: Re: [Pharo-dev] Handling of deprecation packages
>>
>> 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
>>
>>> On 17 Apr 2019, at 23:15, Torsten Bergmann <asta...@gmx.de> wrote:
>>>
>>> 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.
>>>
>>
>>
>>
>>
>
