ubl-ndrsc — archive

[Eduardo Gutentag]

I don't know. It works really well for Docbook; it makes everybody's life simpler and easier. And while I agree that there is a (perceived) need for as fast as possible way to introduce changes, I'm not sure that the need is for incompatible changes. I still think that incompatible changes should be introduced rather slowly. On Mon, 2003-02-10 at 19:51, Eve L. Maler wrote: > It makes for a very long upgrade cycle, and these days I'd be more > inclined to just say that it must be announced only at least one *minor* > revision prior to the major revision's release. The world just moves > faster now, and the advent of XML and -- especially -- XSLT has > increased people's tolerance for simple syntactic upgrades. (For > DocBook's original time, it made a ton of sense.) > > Eve > > Jon Bosak wrote: > > Bill, note this: In Closing Plenary we discussed (Jon brought up) > > that when making a Major change, that will affect backward > > compatibility, that instead of making it in the next Major > > release, you announce the change will be made in the next Major > > release. So this means you actually go through 2 Major releases, > > the second being where the change actually takes place. > > > > I was describing the policy adopted by Davenport for DocBook (as > > well as I could remember it). The policy was that if you are at > > version (N-1).M and you want to make a backwards-incompatible > > change then you don't get to make that change in N.0 but just get > > to announce in release N.0 that the feature will be changed in > > version (N+1).0. > > > > I wasn't urging this, just noting it as something to consider. > > Somewhere along the line we might want to ask the opinions of the > > co-maintainers of that specification back then: Eve Maler and > > Eduardo Gutentag. > > > > Jon -- Eduardo Gutentag e-mail: eduardo.gutentag@Sun.COM Web Technologies and Standards Phone: +1 510 550 4616 x31442 Sun Microsystems Inc. 1800 Harrison St. Oakland, CA 94612 W3C AC Rep / OASIS TAB Chair