Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)

[Kevin <fo...@kegcl.demon.co.uk>]

On Fri, 2005-10-07 at 06:22 -0400, addi wrote:
> On Friday October 07 2005 3:06 am, Ferdinand Soethe wrote:
> > Ross Gardler wrote:
> > > One of our community has raised a concern,
> > > we have to address it. In this case I feel the call is yours as to
> > > whether the changes stay or not (others will speak up if they have an
> > > opinion).
> >
> > Yes 'others' please do!
> 
> Just piping up to say that I definitely agree that this is a fix that needs to 
> be addressed.  I think an explanation in the upgrade docs will suffice.

Yes adding a note to docs sounds good. My concern was a maybe and
I did say unlikely. 

Kevin

> - Addi
> 
> >
> > Problem is the interpretation of bugs and features here and I really
> > think community should clarify this once and for all.
> >
> > For better understanding:
> >
> > 1. The old behavior will overwrite any class-attributes in
> >    table-elements (of any type of document) with class="ForrestTable"
> >    and also set borders= and other presentational attributes right in the
> >    html-code.
> >
> >    My view is that this is broken functionality because
> >
> >    - it makes it impossible to custom format a table with a custom
> >      class-attribute and css (a documented feature).
> >
> >    - it goes against our concept of using css as much as possible.
> >
> >    In fact, a final solution should go even one step further and
> >    replace all presentational attributes in table with css-styling
> >    in the stylesheet.
> >
> >    In summary: I consider the changes to be fixes.  
> >
> > 2. Any change in existing behavior has the potential to break
> >    somebody's Forrest even if it is just fixing a bug.
> >
> >    For example: If somebody tried using their own class-attributes for
> >    table (which had no effect because it was swallowed) they will now
> >    find their custom class tables to have no borders and no more
> >    padding and will have to add extra-css to get them back.
> >
> >    (Pls. note that non-customized tables (without class-attributes) will
> >    continue to work as before!)
> >
> >    I figured that this would be considered to be an improvement
> >    because people who added class="xyz" in the first place likely did
> >    so to customize design, but who knows ...
> >
> > 3. While I accept the general policy of maintaining backward
> >    compatibility, I think this should be limited to documented features
> >    and should always consider what is involved in achieving that goal.
> >
> >    We should _not_ end up creating super complex stylesheets or
> >    bazillions of configuration options to ensure backward
> >    compatibility for bugs or leftovers from previous re-factoring
> >    steps (in this case moving from a non-css to a css-based design).
> >
> >    Especially if all that is required on upgrading would be a piece of
> >    css added to the extra-css in ones project. (A step which I agree
> >    should be documented in the upgrade info).
> >
> > wdyt?
> >
> >
> > --
> > Ferdinand Soethe

Re: General approach to backward compatibility

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:

> Issues should probably be described at our Jira.
> When closing it, declare the svn revision number
> that fixed it. Also in the svn commit, show the
> Jira issue number.

A little time saving hint:

There is no need to put the revision number in Jira as long as you put 
the JIRA number in the commit message (which you should do anyway). Jira 
will provide links directly to the viewsvn pages for that particular 
commit (including revision number).

Ross

Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)

[David Crossley <cr...@apache.org>]

Ferdinand Soethe wrote:
> 
> OK, since we all seem to agree on this I will write some piece for the
> updated docs next week and leave the changes.

Every major change should also be listed in
site-author/status.xml file. A brief note would
suffice and link to other info, such as the updating_*.html
and the Jira Issuue number.

That way people who use the current head SVN
are notified, and it builds the list of Changes.

Issues should probably be described at our Jira.
When closing it, declare the svn revision number
that fixed it. Also in the svn commit, show the
Jira issue number.

The tricky part is knowing when to do such effort
for the documentation.

-David

Re: General approach to backward compatibility (was: Re: Cleaning up html-processing)

[Ferdinand Soethe <fe...@apache.org>]

OK, since we all seem to agree on this I will write some piece for the
updated docs next week and leave the changes.

--
Ferdinand Soethe