FAQ
Actually, I'd rather keep some frequently used methods (such as
DataContext.createChildDataContext()) while it is possible to keep it
correct

2009/11/16 Andrus Adamchik (JIRA) <jira@apache.org>
Remove everything deprecated in 3.0
-----------------------------------

Key: CAY-1310
URL: https://issues.apache.org/jira/browse/CAY-1310
Project: Cayenne
Issue Type: Task
Components: Cayenne Core Library
Affects Versions: 3.1
Reporter: Andrus Adamchik
Assignee: Andrus Adamchik
Fix For: 3.1


Remove all API that was marked as deprecated in 3.0

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

--
Andrey

Search Discussions

  • Andrus Adamchik at Nov 16, 2009 at 1:02 pm
    Then we need to un-deprecate them. I don't want us to be in a limbo
    about deprecated API forever, and starting a new release branch is the
    only chance to sort it out.

    I will keep this particular method around until we have some
    resolution. Also if you have other things in mind, please mention them
    until I get rid of them.

    Andrus
    On Nov 16, 2009, at 2:54 PM, Andrey Razumovsky wrote:

    Actually, I'd rather keep some frequently used methods (such as
    DataContext.createChildDataContext()) while it is possible to keep it
    correct
  • Andrey Razumovsky at Nov 16, 2009 at 1:15 pm
    Well, I'm just looking at usual practice - e.g. Sun JDK still contains some
    methods, deprecated ages ago. Also this allows user to update at once e.g,
    from 2.0 to 3.1 without wondering, where the methods have gone.

    2009/11/16 Andrus Adamchik <andrus@objectstyle.org>
    Then we need to un-deprecate them. I don't want us to be in a limbo about
    deprecated API forever, and starting a new release branch is the only chance
    to sort it out.

    I will keep this particular method around until we have some resolution.
    Also if you have other things in mind, please mention them until I get rid
    of them.

    Andrus


    On Nov 16, 2009, at 2:54 PM, Andrey Razumovsky wrote:

    Actually, I'd rather keep some frequently used methods (such as
    DataContext.createChildDataContext()) while it is possible to keep it
    correct

    --
    Andrey
  • Andrus Adamchik at Nov 16, 2009 at 1:21 pm

    On Nov 16, 2009, at 3:14 PM, Andrey Razumovsky wrote:

    Sun JDK still contains some
    methods, deprecated ages ago.
    I know. Sun is insane with their deprecation policies. The point of
    deprecation is to give people a warning that something's going away
    soon. Not to keep it forever.

    Historically in Cayenne the deprecation timespan was between major
    releases. I.e. the promise is that if something is "deprecated since
    3.0", it won't be in 3.1. Anything more conservative than that would
    just result in an unbelievable code mess.

    In fact I am in favor of shorter major release cycles in large part
    because we'll be able to evolve the framework faster (still giving
    users a proper warning of course).

    Andrus
  • Andrey Razumovsky at Nov 16, 2009 at 1:31 pm
    It is logical to remove all old API when we *assume* that everyone who used
    them has migrated. If 3.1 cycle will again be several years, then we should
    remove everything :) If half a year or less - who knows. BTW I've seen users
    asking about 1.2 version, which had last release years ago and I think it
    was recommended to migrate to 2.0.
    Anyways, feel free to remove that DataContext method as well.

    2009/11/16 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 16, 2009, at 3:14 PM, Andrey Razumovsky wrote:

    Sun JDK still contains some
    methods, deprecated ages ago.
    I know. Sun is insane with their deprecation policies. The point of
    deprecation is to give people a warning that something's going away soon.
    Not to keep it forever.

    Historically in Cayenne the deprecation timespan was between major
    releases. I.e. the promise is that if something is "deprecated since 3.0",
    it won't be in 3.1. Anything more conservative than that would just result
    in an unbelievable code mess.

    In fact I am in favor of shorter major release cycles in large part because
    we'll be able to evolve the framework faster (still giving users a proper
    warning of course).

    Andrus

    --
    Andrey
  • Andrus Adamchik at Nov 16, 2009 at 1:54 pm
    I agree that we need to balance stability and the need to make
    framework changes. I guess we can never achieve 100% pain free
    migration experience for 100% of users, but we'll keep trying.

    As an anecdotal evidence, a year ago I migrated a 1.1 (or was that
    1.0?) Cayenne project to 3.0 for a customer. There were quite a few
    removed methods. I don't have a very long memory, so I simply read
    through all UPGRADE.txt files of intermediate releases, and quickly
    found needed replacements, then applied them via find/replace. The
    important part was that after this purely mechanical substitution the
    old code just worked.

    So actually having a red squiggle in Eclipse for a referenced removed
    class or a method may actually be a good thing - it immediately points
    a user to a problem (as long as there are docs that can help to solve
    this problem).
    Anyways, feel free to remove that DataContext method as well.
    Cool. I will proceed with this task then.

    Andrus
    On Nov 16, 2009, at 3:30 PM, Andrey Razumovsky wrote:

    It is logical to remove all old API when we *assume* that everyone
    who used
    them has migrated. If 3.1 cycle will again be several years, then we
    should
    remove everything :) If half a year or less - who knows. BTW I've
    seen users
    asking about 1.2 version, which had last release years ago and I
    think it
    was recommended to migrate to 2.0.
    Anyways, feel free to remove that DataContext method as well.

    2009/11/16 Andrus Adamchik <andrus@objectstyle.org>
    On Nov 16, 2009, at 3:14 PM, Andrey Razumovsky wrote:

    Sun JDK still contains some
    methods, deprecated ages ago.
    I know. Sun is insane with their deprecation policies. The point of
    deprecation is to give people a warning that something's going away
    soon.
    Not to keep it forever.

    Historically in Cayenne the deprecation timespan was between major
    releases. I.e. the promise is that if something is "deprecated
    since 3.0",
    it won't be in 3.1. Anything more conservative than that would just
    result
    in an unbelievable code mess.

    In fact I am in favor of shorter major release cycles in large part
    because
    we'll be able to evolve the framework faster (still giving users a
    proper
    warning of course).

    Andrus

    --
    Andrey

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedNov 16, '09 at 12:54p
activeNov 16, '09 at 1:54p
posts6
users2
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase