Skip to content
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

Closed
hagenburger opened this issue Jun 3, 2014 · 6 comments
Closed

Versioning #7

hagenburger opened this issue Jun 3, 2014 · 6 comments

Comments

@hagenburger
Copy link
Member

As soon as it is live it should be tagged as v1.0.0 and included in the live version.

@PragTob
Copy link
Member

PragTob commented Feb 5, 2015

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.

@PragTob PragTob mentioned this issue Feb 5, 2015
4 tasks
@finnp
Copy link

finnp commented Apr 1, 2015

I suggest keeping around a version number in the data folder (maybe meta.json) and then use a semver-like versioning:

  • major: significant "breaking" changes
  • minor: additions to the code of conduct
  • patch: correct spelling, formatting

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".

@eljojo
Copy link
Member

eljojo commented Apr 2, 2015

I like @finnp's idea a lot!

@hagenburger
Copy link
Member Author

“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:

  • major: significant “breaking” changes and additions to the code of conduct
  • minor: updating/changing/clarifying existing parts without changing their intension
  • patch: correct spelling, grammar, formatting

Also a list of changes which should not change the version number:

  • Design
  • Browser fixes
  • Adding/removing of supporters
  • Updates in the contacts list of supporters
  • Adding a new language (new languages should always adopt the latest version)

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.

@finnp
Copy link

finnp commented Apr 11, 2015

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.

@1000miles 1000miles mentioned this issue Feb 23, 2016
46 tasks
@skade skade self-assigned this Sep 10, 2017
@1000miles
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants