[docs] Creates release policy document to discuss #1427

Merged
merged 2 commits into from Jan 7, 2013

2 participants

@tokengeek
fog member

This documents the current release policy as it appears (based on the
Rakefile) but may not be comprehensive.

For github issue #1406

@geemus geemus was assigned Dec 27, 2012
@geemus geemus and 1 other commented on an outdated diff Dec 27, 2012
@@ -0,0 +1,39 @@
+# Release process
+
+This is fog's current release process, documented so people know what is
+currently done.
+
+## Versioning
+
+fog uses semantic versioning (http://semver.org/)
+
+## When we release
+
+Releases occur monthly and are manually handled by fog's Benevolent
+Dicator Wes (@geemus).
@geemus
fog member
geemus added a line comment Dec 27, 2012

Should be Dictator.

@tokengeek
fog member
tokengeek added a line comment Dec 27, 2012

LOL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@tokengeek
fog member

@geemus - I've kind of written out the release rake task so there could be any number of things missing!

Writing it out flags a couple of things. We weren't bothering with generating and pushing the API docs so that step is a bit wrong (in the rake task).

Also the updating of the site documentation is part of release but after the commit for that release. So there could be a few files that are changed after the commit.

There's also a bunch of tasks that require credentials to push artefacts places. They are interwoven with things that do not.

I'm actually immediately thinking we split the rake tasks into 1) build/prepare (anyone can do), 2) push release (currently just @geemus) and 3) announce, (which anyone can email the list but not tweet).

@geemus
fog member

@tokengeek - sounds good I think, definitely good to see the omissions and work to break it apart. I think we skip generating/pushing api docs because we assume http://www.rubydoc.info/github/fog/fog/frames will take care of itself (but I guess maybe that isn't really documented or linked to). We should probably fix that.

I was also thinking that it emphasized the value of github pages instead of S3 (as then that portion of the release can be done by more people more easily and need not be tied as closely to versioned releases of fog, where it makes sense). I think it also points out how much of a pain needing all credentials is, short of modularization to allow more granular test running/release I'm not sure what we can do there though (CI might help, but there is cost/danger in having all that go automagically).

@tokengeek
fog member

I have pushed the fog.io as is to gh-pages so we know have docs at http://fog.github.com/fog/ - this is a project set of pages.

I split the docs task out because it was generating the docs then ignoring them (so unrelated to the 'release') then it was uploading them. Apart from sharing a version number and being in the same repo I don't believe they were too coupled. Will move the discussion back to #1281 for that stuff.

@geemus
fog member

@tokengeek - where is the code that the page is coming from? I had thought maybe we should split it out into a separate repo on the fog org and was actually going to work on it today but don't want to step on your toes.

tokengeek added some commits Dec 27, 2012
@tokengeek tokengeek [docs] Creates release policy document to discuss
This documents the current release policy as it appears (based on the
Rakefile) but may not be comprehensive.

For github issue #1406
99756dd
@tokengeek tokengeek [core] Breaks down rake tasks
While documenting our release process, we can see some things that don't
need to be locked together are.

This splits release into prepare/publish parts

Now anyone can prepare a release but will not be able to publish that
release without the correct access to Github and Rubygems.

Adds a preflight task and adds a check for existing tags to that.
28d6e21
@tokengeek
fog member

@geemus - Pushed again to resolve the conflict now that the fog.io rake tasks have gone.

And in case anyone is coming to this later. The question above was answered on another ticket and then superseded. fog.io docs now have their own repo - https://github.com/fog/fog.github.com

@geemus
fog member

@tokengeek - Thanks for updating. Seems good, feel free to merge.

@tokengeek tokengeek merged commit b166bb2 into master Jan 7, 2013

1 check passed

Details default The Travis build passed
@tokengeek tokengeek deleted the release_notes branch Jan 7, 2013
@geemus
fog member

@tokengeek - Thanks, you are awesome!

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