We currently follow the Semantic Versioning specification which is kind of the de-facto-standard versioning scheme for software that have some kind of an API ( or some kind of user-facing and non-user-facing interface ). However, we are a font project and we do not have 'interfaces'.
One of the core focuses of the project when it was forked was to maintain maximum compatibility with Font Awesome 4.7.0. It is highly unlikely that Fork Awesome would ever make a major release ( v1 -> v2 ). We would most probably be upgrading the minor and patch release versions.
Considering the 2 reasons I have described above, I am proposing to switch the versioning scheme to Calendar Versioning scheme.
It is unlikely that we would make more than one release per month, so my proposal is to use YY.0M ( the same scheme as Ubuntu ). In the rare case that we are forced to make a second release in the same month, we could use YY.0M.0D.
We currently follow the Semantic Versioning specification which is kind of the de-facto-standard versioning scheme for software that have some kind of an API ( or some kind of user-facing and non-user-facing interface ). However, we are a font project and we do not have 'interfaces'.
One of the core focuses of the project when it was forked was to maintain maximum compatibility with Font Awesome 4.7.0. It is highly unlikely that Fork Awesome would ever make a major release ( v1 -> v2 ). We would most probably be upgrading the minor and patch release versions.
Considering the 2 reasons I have described above, I am proposing to switch the versioning scheme to Calendar Versioning scheme.
It is unlikely that we would make more than one release per month, so my proposal is to use
YY.0M( the same scheme as Ubuntu ). In the rare case that we are forced to make a second release in the same month, we could useYY.0M.0D.