Uploaded image for project: 'PUBLIC - Liferay Documentation'
  1. PUBLIC - Liferay Documentation
  2. LRDOCS-10198

Broad Consideration for LRL Content: more clear language for replacement and deprecation


    • New Article
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • master
    • Website
    • None
    • User


      Split ticket LRDOCS-10173 into this ticket

      Task: (on LRL site as a whole) Review documentation language around replacement of our deprecated apps, to see if we can be clearer.

      Slack thread for context:

      Comments from joel.garman:

      "Typically as part of the release process https://issues.liferay.com/browse/RELEASE-3167

      1. I would not assume that if a replacement is identified for a feature it implies that a data migration path is present
      2. I also would not assume that replacement has bearing on the future availability of the feature. Basically, replacement doesn't dictate if the feature will or will not be available
      Like Russ said, it would be ideal if the term "replacement" or "replaced" had implications for data and future availability but it doesn't.

      I think what would help is to identify if there is a data migration path or not. This way the customer could properly plan for their upgrade and understand the level of effort it would take to move from X to Y feature or if they need to

      Russ: For the data migration question, maybe #t-dxp-bravo would be the place to ask? [Although Luiz might know, and is probably seeing it here too]

      Joel: Technically, according to the deprecation process data migration is needed in order to archive a feature or module so that we don't leave orphaned data in the DB, but that's not always followed


        Issue Links



              km.material KM Material
              andrew.wilkinson Andrew Wilkinson (Inactive)
              Nicole Mak Nicole Mak (Inactive)
              0 Vote for this issue
              0 Start watching this issue




                  Version Package