-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Versioning #7
Comments
Bump. Hugely important when we want to amend this code of conduct and add new rules as we can't just change it as quite some user groups are referring to it. |
I suggest keeping around a version number in the data folder (maybe meta.json) and then use a semver-like versioning:
After a PR gets merged, someone changes the version number as well. Organizers get informed at least about minor and major changes, probably not about "patches". |
I like @finnp's idea a lot! |
“Additions” is not like adding a feature in software without breaking it. It might make it stricter which you might compare to removing a feature (breaking). I would go for:
Also a list of changes which should not change the version number:
For the process: We can’t just update the version number after pull requests. As long as it’s more than a patch, all languages have to be updated first. |
Right now PRs are against master and then deployed to gh-pages right? So the versioning could be done before publishing to gh-pages. Also maybe there should be all versiong available online like http://berlincodeofconduct.org/1.2.0, so people can link it directly? Then this page could also show a deprecation warning for oganizers to update them? But maybe that's a bit too complicated. |
Update, Sun, 2017-09-10 Today @yuiofthesun, @skade and me decided to use tagging for the releases (as previously proposed by @hagenburger ) and link them from the website. Closing. |
As soon as it is live it should be tagged as v1.0.0 and included in the live version.
The text was updated successfully, but these errors were encountered: