One thing that would immensely help developers and podmins alike would to be adopt a time-based release cycle. Ubuntu, for example, does a release every six months, and while they have some larger overreaching goals, they only really have to worry about the immediate six-month roadmap for improving the platform.

Similarly, moving to a versioning scheme beyond calling it "Alpha" or "Beta" might be a better indicator of progress on what's getting done. It would encourage podmins to pull from stable releases rather than just GitHub upstream,

See http://semver.org/.

With the following changes:

In our case API is defined as:
- Our frontend (major changes -> major version, minor changes -> minor version, you'll get the idea).
- The federation protocol.
- The client API (not existent yet)

Big internal and structural changes that do not influence the users of all sort (users, client developers, pods), except perhaps for performance, still only justify a minor version.

The version is prefixed with another number which will be increased at community decision instead of a major release. This is to avoid a false sense of rapid development and increasing stability while still maintaining a meaning in the version number changes from the start.

The first version to release will be 0.0.1