Smalltalk › Amber Smalltalk

Deprecated stuff

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Herby Vojčík

Deprecated stuff

Hi!

Amber contains decent number of deprecated stuff coupled with
backward-compatibility workarounds. I have the impression Amber codebase
could breath lighter if those were gone.

I have the idea to set the cutoff date (end of 2014) and at that date
remove all this cruft and release 0.14.0 no matter what. It would be
compatible with 0.13.x, no big changes added (just state of the art at
that date), but main thing about it would be that deprecated stuff will
be gone (that's why 13 needs increase to 14).

(yes, I know 0.13 is not out yet, but it may be any day)

What do you think? Is the transition period too short? Or, coupled with
clear announcement there will be deprecation-removal release of 0.14.0
at 1-1-2015 it can go well?

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Andy Burnett

Re: Deprecated stuff

My personal view is that we need to build the best possible system we can. Backward compatibility - at this stage - would be a hindrance to our later success. However, we don't have any critical systems built in Amber - yet - so I do appreciate that my view is biased.

Cheers

Andy

On Sun, Oct 5, 2014 at 10:52 AM, Herby Vojčík <[hidden email]> wrote:

Hi!

Amber contains decent number of deprecated stuff coupled with backward-compatibility workarounds. I have the impression Amber codebase could breath lighter if those were gone.

I have the idea to set the cutoff date (end of 2014) and at that date remove all this cruft and release 0.14.0 no matter what. It would be compatible with 0.13.x, no big changes added (just state of the art at that date), but main thing about it would be that deprecated stuff will be gone (that's why 13 needs increase to 14).

(yes, I know 0.13 is not out yet, but it may be any day)

What do you think? Is the transition period too short? Or, coupled with clear announcement there will be deprecation-removal release of 0.14.0 at 1-1-2015 it can go well?

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Manfred Kröhnert

Re: Deprecated stuff

Most projects I know add a deprecation warning in release X and remove the deprecated stuff in release X+1.

So I think it makes sense to remove the deprecations in 0.14.0.

After hitting 1.0.0 we should think about which releases actually do remove deprecations (x+1.*.* or *.x+1.*).

It would also be important to decide which part of the number to increase when methods are added and so on.

Or are some decisions already made by using the Semantic Versioning approach?

This should also be documented somewhere in the developer documentation.

Best,

Manfred

On Sun, Oct 5, 2014 at 5:04 PM, Andy Burnett <[hidden email]> wrote:

My personal view is that we need to build the best possible system we can. Backward compatibility - at this stage - would be a hindrance to our later success. However, we don't have any critical systems built in Amber - yet - so I do appreciate that my view is biased.

Cheers
Andy

On Sun, Oct 5, 2014 at 10:52 AM, Herby Vojčík <[hidden email]> wrote:
Hi!

Amber contains decent number of deprecated stuff coupled with backward-compatibility workarounds. I have the impression Amber codebase could breath lighter if those were gone.

I have the idea to set the cutoff date (end of 2014) and at that date remove all this cruft and release 0.14.0 no matter what. It would be compatible with 0.13.x, no big changes added (just state of the art at that date), but main thing about it would be that deprecated stuff will be gone (that's why 13 needs increase to 14).

(yes, I know 0.13 is not out yet, but it may be any day)

What do you think? Is the transition period too short? Or, coupled with clear announcement there will be deprecation-removal release of 0.14.0 at 1-1-2015 it can go well?

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Herby Vojčík

Re: Deprecated stuff

Manfred Kröhnert wrote:
> Most projects I know add a deprecation warning in release X and remove
> the deprecated stuff in release X+1.
> So I think it makes sense to remove the deprecations in 0.14.0.

Well, there are deprecation message for long time there already. ;-)

> After hitting 1.0.0 we should think about which releases actually do
> remove deprecations (x+1.*.* or *.x+1.*).
> It would also be important to decide which part of the number to
> increase when methods are added and so on.
> Or are some decisions already made by using the Semantic Versioning
> approach?

Probably not officially, but I try to be semver-compatible, more-or-less. Though, it is still more about an intuition (added is fine, changed/removed is worse).

> This should also be documented somewhere in the developer documentation.
>
> Best,
> Manfred
>
>
> On Sun, Oct 5, 2014 at 5:04 PM, Andy Burnett
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>

My personal view is that we need to build the best possible system

> we can. Backward compatibility - at this stage - would be a
> hindrance to our later success. However, we don't have any
> critical systems built in Amber - yet - so I do appreciate that my
> view is biased.
>
> Cheers
> Andy
>
> On Sun, Oct 5, 2014 at 10:52 AM, Herby Vojčík <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Hi!
>
> Amber contains decent number of deprecated stuff coupled with
> backward-compatibility workarounds. I have the impression
> Amber codebase could breath lighter if those were gone.
>
> I have the idea to set the cutoff date (end of 2014) and at
> that date remove all this cruft and release 0.14.0 no matter
> what. It would be compatible with 0.13.x, no big changes added
> (just state of the art at that date), but main thing about it
> would be that deprecated stuf

f will be gone (that's why 13

> needs increase to 14).
>
> (yes, I know 0.13 is not out yet, but it may be any day)
>
> What do you think? Is the transition period too short? Or,
> coupled with clear announcement there will be
> deprecation-removal release of 0.14.0 at 1-1-2015 it can go well?
>
> Herby
>
> --
> You received this message because you are subscribed to the
> Google Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to [hidden email]
> <mailto:amber-lang%[hidden email]>.
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving email

s from it,

> send an email to [hidden email]
> <mailto:[hidden email]>.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email]
> <mailto:[hidden email]>.
> For more options, visit https://groups.google.com/d/optout.

sebastianconcept

Re: Deprecated stuff

In reply to this post by Herby Vojčík

Makes sense.

I’m good with that.

I’ve already not depending on deprecations, so no objections here.

On Oct 5, 2014, at 11:52 AM, Herby Vojčík <[hidden email]> wrote:

> Hi!
>
> Amber contains decent number of deprecated stuff coupled with backward-compatibility workarounds. I have the impression Amber codebase could breath lighter if those were gone.
>
> I have the idea to set the cutoff date (end of 2014) and at that date remove all this cruft and release 0.14.0 no matter what. It would be compatible with 0.13.x, no big changes added (just state of the art at that date), but main thing about it would be that deprecated stuff will be gone (that's why 13 needs increase to 14).
>
> (yes, I know 0.13 is not out yet, but it may be any day)
>
> What do you think? Is the transition period too short? Or, coupled with clear announcement there will be deprecation-removal release of 0.14.0 at 1-1-2015 it can go well?
>
> Herby
>
> --
> You received this message because you are subscribed to the Google Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.