v1.0 plans #940
Description
With v0.25 released, I think it would be useful to communicate future plans in advance.
Unless something unforeseen happens to require another 0.x release, the next release is planned to be v1.0; the timeline is "when it's done", but I would expect this to happen this year in November-December time frame.
The number, in some sense, is just a number: there will be a v1.1 after that. The major version is meaningful in semver sense, however meshoptimizer has a slightly different compatibility policy in general, where minor releases do not break source or binary compatibility, except for APIs that are marked as experimental. This is expected to continue during 1.0 cycle: new APIs will be introduced as experimental, possibly change in minor releases, and then get stabilized and not change after that. This ensures the library can continue to evolve at the pace it needs to.
However, in some sense, the library has been 1.0 in spirit for a little while now: it's quite production ready, being used in many production engines, games, and non-graphics software, and the compatibility policy outlined above makes using even 0.x versions "safe". After 8 years since the first numbered release (v0.5 was released in July 2017), it's about time.
The focus in v1.0 will be on stabilization. The last few versions have front-loaded a lot of new experimental features, in the form of new algorithms, simplification modes, etc.; some of these have been stabilized in v0.25, and the main focus in v1.0 will be on getting all of the existing APIs to stable. This may mean stabilizing them without further changes, or continued implementation work, or changing the interface.
Ideally, v1.0 ships with all APIs as stable. This creates a potential issue: what if new APIs are needed in v1.0 time frame, do we not ship them at all? Do we ship them as experimental? We'll see. My current expectation is that no significant new APIs will be created, but there might be somewhat more straightforward extensions - specifically, for meshlet repacking re: #922 - that get introduced as stable.
One thing that will probably change post-1.0 is the use of experimental APIs - at least when that affects ABI - in gltfpack. With v0.24, you can now build meshoptimizer as a shared library without experimental APIs, by using MESHOPT_STABLE_EXPORTS configuration - I would expect that to be useful for Linux distributions as they can build libmeshoptimizer.so.1 (via MESHOPT_SOVERSION=1) which is guaranteed to be ABI stable across minor releases. However, if gltfpack ever uses experimental APIs like it does today with meshopt_simplifySloppy, that would not work for gltfpack build. So it might be a good idea to, from 1.0 forward, to only ever use experimental APIs in gltfpack if that usage is ABI safe; this may delay introduction of some features to gltfpack but that's probably okay as a compromise.