gwyneplaine
commented
5 years ago Agreed that versioning this work is important, thanks @elisechant
We can iterate on a more robust versioning methodology as we proceed, but I've added a package.json at version 0.0.1 to reflect the infancy of this project.
My initial sense is to lean on semver here:
- 0.x.x until we get to a stable state for the guide
- Standard practice around semver for major , minor and patch changes post 1.x
We'll need to think deeply about what major minor and patch means in the context of documentation, happy to hear your thoughts here
As this is a public repo and if the concept of this repo (I assume) is "how can we herald design system best practice?", and the audience is "community" or "clients" (ie, not us), it might be an idea to follow software best practice and include versioning for this repo.
If that's not relevant, maybe the theoretical content of this repo should be Github Wiki instead.
I think versioning is a good idea particularly at this stage, because it tells people, "we're still working on this content, please don't rely on it as evidence of good practice to reference or follow just yet".
Whether we capture versioning by including a package.json, or including a version.txt or simply to expand on what you've already indicated in the README that the "software" is "very wip", let's call it something and escalate that version to the top of the document.
In the future, we might have indications of what's coming in the next releases documented somewhere where versioning might be needed. Perhaps we want to externalise "what do we plan to deliver for Alpha?", "what do we plan to deliver for 1.0.0?", "what is the estimated scheduling for that?", "what do we need and perhaps who in the community do we need to seek expert help from (ie, Designers, Researchers) in order to be able to release Alpha?".