[
https://issues.apache.org/jira/browse/TRINIDAD-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803065#action_12803065
]
Jeanne Waldman commented on TRINIDAD-1691:
------------------------------------------
Why isn't putting the version into the skin-family name good enough?
<skin-family>purple1.1.12.4</skin-family>. It's not quite the same as
versioning, since we wouldn't change the version number every time we release.
> Skinning framework support for skin versioning
> ----------------------------------------------
>
> Key: TRINIDAD-1691
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1691
> Project: MyFaces Trinidad
> Issue Type: New Feature
> Components: Skinning
> Reporter: Matt Cooper
>
> UI designers periodically create new UI designs for various components with
> the goal of these designs being applied to a specific skin. Although the
> visual design might be completely new for a given component, it is really
> meant to be available in context of other existing component designs of the
> same existing skin.
> UI changes like this are sometimes considered to jarring for some customers
> and they would rather stick with the original designs. This means that skins
> are eternally frozen after their first release so any new changes would need
> to be made in a new skin even though that new skin might be 75% identical to
> the original skin.
> There is also a negative impact on customers that generate their own skin
> definitions when we introduce a new skin name. Every skin (or skin addition)
> that they have created won't be able to uptake the new designs unless they
> physically go in and change all references from the old skin name to whatever
> the new skin's name is. To remedy this while enabling the "frozen" state of
> the original designs, the skinning framework must support a concept of
> versioning. Since the nature of software means that code lines branch into a
> vast tree structure, the version numbers of the skinning framework must
> fulfill this need. A simple "x.y" will not be sufficient, we will require
> "x.y.z.a.b.c.d.e.f.g" and so on where each "." represents another code branch
> off of the previous code branch, e.g. there will likely be a version that
> looks like "1.1.12.4".
> Customers will then need a configuration option where they can specify which
> version of the skin they want to use. (Presumably near the same location
> where they specify which skin name they want to use.)
> Business needs:
> Some customers need new UI designs applied to existing skins but other
> customers need the skin to remain unchanged. Versioning will allow customers
> to optionally buy-into the new UI designs while other customers can happily
> live with the past designs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
