Since this is a fork of the archived jgraph/mxgraph and since it changed its name to maxGraph, it is a good chose to rest the version number, what I noticed in the package.json files.

It is always a good practice to use a clear versioning strategy to reduce the cognitive load for everyone developing and using this library. These days the Semantic Versioning approach is followed by many (maybe majority) of libraries and softwares.

... we propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. ... For this system to work, you first need to declare a public API. ... Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

Regrading the current status of the project which is maybe prune to heavy changes in the public API, I suggest that we my start with version 0.1.0 as @tbouffard proposed in his draft #87 . The Semantic Versioning 4th rule states that the major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

When publishing a pre-release we just have to add a prefix like -alpha -beta -beta.1 -beta.2 -rc
The Semantic Versioning spec do not add any further rules concerning 0.y.z version but we can just apply the same rules for the x.y.z where x >= 1in a best effort way.

Proposal:

• Start with version 0.1.0-alpha for internal usage and testing. (Could be event published on npm this way)
• Increment the PATCH when integrating bug fixes
• Increment the MINOR when adding new feature and/or refactoring and/or removing features.
• When you think that others can use it and you want their feedback from a user point of view (developer that integrates this library), publish the version without -alpha suffix or replace it with a -beta suffix (i.e. 0.2.5-beta). IMO I do not think it's necessary to use a -beta suffix for 0.y.z versions since they are all considered in the development phase.
• When things get stabilized enough, publishing the 1.0.0 series could start (start with -alpha -beta -rc suffix)

Notes:

• We can create a dedicated issue related to the roadmap of the 0.1.0 version.
• The old ChangeLog file must be taken into consideration. It may be archived or we can simply add a separator to start a new chapter.

Related issues/discussions:

• chore: improve the configuration to build the npm package #87
• Steps required for publishing package #41
• ES9 conversion and validation #18 (reply in thread)