Proposal Regarding The OpenOffice.org Numbering Scheme

Last updated: 2002-02-14

Update: The community voted overwhelmingly in favor of this proposal. It is now accepted. The build to become 1.0 is not the current one but a future one, to be made available early next quarter of this year.

Proposal

This proposal was developed by a consensus process on the OpenOffice.org Marketing list. We are proposing it to several other OpenOffice.org mailing lists as a plebiscite in order to gauge the general community opinion of the idea. Please be assured that we are not able to "force" a change on anybody; instead, we are putting this forward as something we think the community will wholeheartedly approve.

OpenOffice.org will continue to use the build numbers (e.g. 641C, 647) for internal reference. We are not proposing to tell the developers how to refer to their program, for which build numbers are apparently the most convenient means.

But for purposes of general intelligibility, and to accommodate a general expectation of how an Open Source project should number its public releases, an "X.Y.Z" numbering scheme will be adopted around the time of the release of StarOffice 6.0 this spring. Instead of referring to OpenOffice.org by its internal number (e.g., 64x), people will be able to refer to it by the new numeration. All downloads will use this form. This proposed numbering scheme serves four purposes:

Providing an identifier for the common user interfaces, such as: Splash Screen, Title Bar, About Page, Installation Wizard, Web Page.
Translating OpenOffice.org build numbering into a simpler value which is more easily comprehended by the general public and the press.
Building our image that OpenOffice.org is a separate and useful product in its own right, not only a part of the StarOffice development process.
Giving the impression, at the correct time, that OpenOffice.org is ready for production use by businesses and individuals.

The first version number will be "1.0.0".

Please review this proposal. We would like for discussion and vote to conclude by then end of next week: The deadline is Friday, 2002 Feb. 8.

Voting will be +1, -1, and indicate approval or disapproval. Feel free to comment, make suggestions, and contribute. Any OpenOffice.org member may vote; but members must submit their vote to the "discuss" list, users@openoffice.apache.org; unsubscribed members will have their submissions moderated.

Examined Alternatives (Found Unsatisfactory)

The following three alternate numbering schemes were debated on the Marketing list and rejected for the reasons named.

"OpenOffice.org 6.0"

By synchronizing OpenOffice.org and StarOffice version numbers, we perpetuate the existing public impression that OpenOffice.org is strictly a StarOffice development project. This impression impairs our ability to attract independent developers and to encourage OpenOffice.org use in businesses.
We have not had five previous versions of OpenOffice.org. Jumping straight to version 6, while it would re-assure may users accustomed to Microsoft product numbering, would alienate some Unix and Open Source developers due to the pretense involved. In this light, version 1.0 is seen as a good compromise between the Windows and Unix/Open Source worlds.

"OpenOffice.org 2002"

It could be perceived by many as slavishly imitating Microsoft.
The "year" scheme does not allow for the release of multiple stable versions of the product in a single year. It also complicates patch releases by requiring long version numbers like "OpenOffice.org 2002 r.3.1" which might confuse the general user.

"OpenOffice.org 0.8.5 (or .9.x)

It was suggested that we release OpenOffice.org as a "less than 1.0" release and work towards a perfect, 1.0, product. This is in keeping with the tradition of Open Source development. However, the general Windows-using public would perceive any number less than 1.0 as being an alpha version and not suitable for general use. As the entire purpose of a version numbering change is to market OpenOffice.org to the public, such a scheme would be self-defeating.

As said above, we felt that a "Version 1.0.0" on a product with some missing features and bugs but a lot of excellent functionality was a good compromise between "0.8.5" and "6.0".

To examine the threads of this discussion, please refer to the Marketing list archives. Several key threads include: