#115: Formalized User Interface deprecation process

Contents
  1. Motivation
  2. Proposal
  3. Implementation
  4. Risks
by Alex Limi last modified Jan 21, 2010 07:26 AM

Provide a sensible way to deprecate the user interface elements that provides predictability for product authors and ease-of-use for the Plone developers.

Proposed by
Alexander Limi
Proposal type
Process
Assigned to release
State
completed

Motivation

At the moment, it's very hard to deprecate Plone user interface elements — be it icon renaming, CSS class deprecation or other elements impacting the front-end of Plone - including Python Scripts.

On the code level we have deprecation warnings, but we need something that will do the job in the HTML, JS, CSS, Python Script and template space.

There is currently no clear process on how this works, and although there are some efforts in place already (the deprecated.css file, for example), we need a way to deprecate anything in the UI front in a predictable way for third-party product authors, so they can easily see what needs to be updated before the next release of Plone comes out to remain compatible.

This deprecation process should also be low-impact for Plone-the-product itself, and easy to use for its developers.

Proposal

  • Create skin layer plone_deprecated, and move all deprecated elements there with a note about which release it will disappear in.
  • Its contents of this are included for two releases, so product authors can support current+future release or previous+current release. In that way, the current release will always be supported, and product developers have the space between releases to prepare for the upcoming release.
  • Product authors are reminded to turn off that skin layer to future-proof their products.

This is not a perfect process, but will make it at least a bit easier to deprecate UI elements and keep up to date as a product author. I believe it's important to keep this lightweight, and I believe this approach is Good Enough.

Implementation

Implementing this should be very simple - add one skin layer, and keep track of (inside the files themselves, most likely with BBB markers) what release a particular file is removed.

That way, product authors can simply remove this layer in their skins to see what will break in the upcoming release.

Risks

  • Leads to an additional skin layer to keep track of.
  • Needs to be documented properly, and product authors need to be reminded to turn off the deprecated layer in each release to make sure their product will work in the upcoming version.
  • We should maybe consider supporting the deprecated elements for two releases. This would be implemented the same way, just with two skin layers instead.

Comments (0)