> I'd like to revisit Gavin's proposal for a polite way to extend VRML.
> Here's an excerpt from a message he sent on 2/21:
>
> >I guess I'm looking for some concensus on the polite way of adding new
> >features to the VRML spec. Something like:
> >
> >1. Implement as an experimental feature. Implement in such a way that
> > users know that they are using an experimental feature
> >2. Propose to VRML mailing list. Discuss, debate, convince.
> >3. Others implement/use the new feature.
> >4. New feature becomes part of the "official" VRML spec.
>
> I like his proposal. It's organic. How about you all?
I'm not sure how well this would fit in here, but the Linux release
system uses two semi-separate systems for numbering releases. The major
version number is common. The odd minor versions have a sub-minor
number that changes quickly. Odd minor versions get little review, and
additions are made frequently. They are considered to be in continual
"Alpha" release. The even minor versions are subjected to an extensive
review, and their sub-minor number changes rarely. Even minors versions
are considered to be "Stable" releases, and are made up of one of the
"best" of the alpha releases. For Example:
Linux v. 1.0.8 is the eighth stable release of 1.0, and was
(hypothetically) 1.1.44, when it was alpha.
Linux v. 1.1.59 is the 59th alpha release of 1.0
Linux 1.0.0 and 1.1.0 were identical, so when they go to 1.2.0 (stable),
that release also becomes 1.3.0, and again, the odd one changes fast, the
the even one changes slow.
If we use this system for VRML, then only 1.0, 2.0, 3.0 ... would be
"Standards", while the rest of the releases would be experimental
additions (Odd minor numbers) or draft standards (even minors).
We also need one central authoritative site which can act as an integrator
of features (thereby creating new releases), and a repository of change
records, bug reports, documents, and, optionally, software and pointers to
other VRML oriented resources which can be used by developers to create
more enhancements.
---
Andrew C. Esh mailto:[email protected]
Computer Network Technology [email protected] (finger for PGP key)
6500 Wedgwood Road 612.550.8000 (main)
Maple Grove MN 55311 612.550.8229 (direct)
<A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>