# Promoting OpenGL Extensions

Promoting an extension refers to moving it from single-vendor to multi-vendor or ARB-approved status, usually by changing the vendor tag attached to the extension name string, enumerants and API entry points. This is sometimes done when an extension is successful and more licensees want to support it. This document describes the steps to follow when promoting an extension.

### Is Promotion Required?

Changing the names creates a significant burden for ISVs supporting the existing extension. It should not be done gratuitously; if the existing interface is sufficient, there's no inherent reason an implementation shipped by one vendor cannot advertise and support an extension using another vendor's prefix.

If you do this, make certain that the original vendor agrees to freeze the definition of the extension, and that what you ship is identical in behavior to what the original vendor is shipping. Shipping what appears to be the "same" extension while implementing different behavior on multiple platforms is a great disservice to ISVs trying to use extensions, and to OpenGL in general.

Do not, under any circumstances, ship an extension defined by another vendor without first clearing it with that vendor.

### Promoting Without Changes in Behavior

If you nevertheless want to promote an extension from vendor-specific to e.g. `EXT` status, without changing the behavior or definition of that extension, then advertise and export both the old and the new forms of the extension for maximum backwards compatibility. This means that:

- Both extensions strings should be included in the `GL_EXTENSIONS` string query (or the corresponding WGL/GLX query, if it extends those APIs).
- All enumerants should exist in both `GL_VENDOR_ENUM_NAME` and `GL_EXT_ENUM_NAME` forms, with the same values.
- All entry points should exist in both glExtensionNameVendor and glExtensionNameEXT forms, resolving to the same code.
- For an extension supported under GLX, the same GLX protocol should be generated no matter whether the vendor or `EXT` version of the extension is called.

### Promoting With Changes in Behavior

If you are promoting an extension while changing its definition or behavior, do not treat it as identical to the old extension. This means that:

- Any new `EXT` enumerants which differ in definition from the original `VENDOR` enumerants should be assigned new values, and those values registered with SGI.
- All new EXT entry points should resolve to different code in the GL client library than the original Vendor extension entry points.
- For an extension supported under GLX, different GLX protocol requests should be generated for the two extensions, so they can be distinguished on the server side.

None of this should be taken to indicate that code cannot be shared between implementations of the old and new extensions; simply that the implementation must be able to distinguish whether the old or new form is being called, since they are de facto different extensions despite sharing similar purposes.

Last modified April 5, 1999 Jon Leech