Deprecated long overdue in 5.3

Hi Karl,

> On Oct 18, 2018, at 3:29 AM, karl ramberg <[hidden email]> wrote:
>
> Hi,
> We have several methods that have been deprecated for several releases. We should prepare for removal of these now in the beginning of 5.3

+1.  We should remove the 4.x packages ASAP.  But what’s the right way to remove a package?  I guess if one wants to remove an MNDeprecated package one can add a script to the MN+1Deprecated package.  Is there a better way?

> Best,
> Karl

On Thu, 18 Oct 2018, Eliot Miranda wrote:

> Hi Karl,
>
>> On Oct 18, 2018, at 3:29 AM, karl ramberg <[hidden email]> wrote:
>>
>> Hi,
>> We have several methods that have been deprecated for several releases. We should prepare for removal of these now in the beginning of 5.3
>
> +1.  We should remove the 4.x packages ASAP.  But what’s the right way to remove a package?  I guess if one wants to remove an MNDeprecated package one can add a script to the MN+1Deprecated package.  Is there a better way?

Since you have to bump the version number of the Squeak-Version
package anyway when you unload a package to ensure the monotonicity of the
global version number, the common practice is to add the unload script as
the postscript of that package. A line such the one below should do it:

(MCPackage named: '<name of the package to unload') unload

Levente

P.S.: do not remove 39deprecated yet. It's minimal, and it contains two
methods that we need if we want to migrate from SharedQueue to
SharedQueue2.

>
>> Best,
>> Karl

Yes, please let's get some of the deprecation actually done - or what's the point?

And as a side question what can we do about cases where we have not-very-nice class names because of making replacement versions? 'SharedQueue2' isn't the best of names. I'd much prefer the deprecation process replaced the old with new, though I understand there are potential issues.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange Opcodes: ZZZZZZZZZZZZ: enter sleep mode