Smalltalk › Squeak › Squeak - Dev

Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

marcel.taeumel (old)

Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

Hi ---

We should unload all historic deprecations... and focus on what is needed for 46Deprecated (if it cannot be deleted).

Best,
Marcel

David T. Lewis

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

On Fri, May 01, 2015 at 05:23:15AM -0700, Marcel Taeumel wrote:
> Hi ---
>
> We should unload all historic deprecations... and focus on what is needed
> for 46Deprecated (if it cannot be deleted).
>

It might be better to do this immediately after the next release, rather than
before. Removing things can have unintended side effects, so it is good to do
it earlier in the release cycle.

Dave

Tobias Pape

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

On 02.05.2015, at 15:07, David T. Lewis <[hidden email]> wrote:

> On Fri, May 01, 2015 at 05:23:15AM -0700, Marcel Taeumel wrote:
>> Hi ---
>>
>> We should unload all historic deprecations... and focus on what is needed
>> for 46Deprecated (if it cannot be deleted).
>>
>
> It might be better to do this immediately after the next release, rather than
> before. Removing things can have unintended side effects, so it is good to do
> it earlier in the release cycle.

Those things (39 and 311) have been deprecated for long, so I'd rather
say to lose them right before and keep 45 around one more cycle…
Best
-Tobias

Hannes Hirzel

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

+1
In particular as there will be another two or three months until the
release takes place....

--Hannes

On 5/2/15, Tobias Pape <[hidden email]> wrote:

>
> On 02.05.2015, at 15:07, David T. Lewis <[hidden email]> wrote:
>
>> On Fri, May 01, 2015 at 05:23:15AM -0700, Marcel Taeumel wrote:
>>> Hi ---
>>>
>>> We should unload all historic deprecations... and focus on what is
>>> needed
>>> for 46Deprecated (if it cannot be deleted).
>>>
>>
>> It might be better to do this immediately after the next release, rather
>> than
>> before. Removing things can have unintended side effects, so it is good to
>> do
>> it earlier in the release cycle.
>
> Those things (39 and 311) have been deprecated for long, so I'd rather
> say to lose them right before and keep 45 around one more cycle…
> Best
> -Tobias
>
>
>
>

marcel.taeumel (old)

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

In reply to this post by David T. Lewis

Then I might not quite understand the idea of deprecating things here. :) How many releases should they stay?

We should at least add tests so that there are no senders in the image left.

Best,
Marcel

marcel.taeumel (old)

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

Any project that needs those things can load them. Anytime. Why keep them in trunk?

Best,
Marcel

Levente Uzonyi-2

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

In reply to this post by Tobias Pape

The problem here is that some of these have assumptions which have never
been met.
39Deprecated:
- ContextPart >> #methodSelector can be safely removed
- SharedQueue2 >> #flush and #flushAllSuchThat: can be removed, but that
will make it incompatible with SharedQueue. The migration to SharedQueue2
has not happened yet, so these methods have senders in the image (even if
the receiver is not a SharedQueue2). And it's possible that we'll migrate
to something else.
311Deprecated: Everything looks safe to be removed.
45Deprecated: Most methods seem to be safe to be removed.

Levente

On Sat, 2 May 2015, Tobias Pape wrote:

>
> On 02.05.2015, at 15:07, David T. Lewis <[hidden email]> wrote:
>
>> On Fri, May 01, 2015 at 05:23:15AM -0700, Marcel Taeumel wrote:
>>> Hi ---
>>>
>>> We should unload all historic deprecations... and focus on what is needed
>>> for 46Deprecated (if it cannot be deleted).
>>>
>>
>> It might be better to do this immediately after the next release, rather than
>> before. Removing things can have unintended side effects, so it is good to do
>> it earlier in the release cycle.
>
> Those things (39 and 311) have been deprecated for long, so I'd rather
> say to lose them right before and keep 45 around one more cycle…
> Best
> -Tobias
>
>
>
>

Tobias Pape

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

In reply to this post by marcel.taeumel (old)

On 02.05.2015, at 21:25, Marcel Taeumel <[hidden email]> wrote:

> Then I might not quite understand the idea of deprecating things here. :) How
> many releases should they stay?
>

n+2.

So ideally,
45Deprecated should be removed in 4.7
46Deprecated should be removed in 4.8

and so on. That's how I understand deprecation

> We should at least add tests so that there are no senders in the image left.
>
> Best,
> Marcel

Best regards
-Tobias

David T. Lewis

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

In reply to this post by marcel.taeumel (old)

On Sat, May 02, 2015 at 12:27:38PM -0700, Marcel Taeumel wrote:
> Any project that needs those things can load them. Anytime. Why keep them in
> trunk?
>

I only meant to suggest that it may be better to do it immediately after the
release, not that it shouldn't be done. It's the same amount of work either
way, just less chance of causing problems for the release image. Nobody who
downloads the 5.0/4.6 image would notice the difference either way.

Dave

David T. Lewis

Re: Unload 39Deprecated, 311Deprecated, and 45Deprecated in Trunk

On Sat, May 02, 2015 at 03:59:45PM -0400, David T. Lewis wrote:

> On Sat, May 02, 2015 at 12:27:38PM -0700, Marcel Taeumel wrote:
> > Any project that needs those things can load them. Anytime. Why keep them in
> > trunk?
> >
>
> I only meant to suggest that it may be better to do it immediately after the
> release, not that it shouldn't be done. It's the same amount of work either
> way, just less chance of causing problems for the release image. Nobody who
> downloads the 5.0/4.6 image would notice the difference either way.
>

Sorry, please disregard. I'm falling behind :-(

Dave