Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Documented release process #1406

Closed
tokengeek opened this Issue Dec 20, 2012 · 8 comments

Comments

Projects
None yet
4 participants
Owner

tokengeek commented Dec 20, 2012

At the moment fog releases are done (sort of) monthly by @geemus or on demand.

Every so often someone asks for a release, frequently because of a new AWS endpoint or a feature they have added.

(Putting aside solutions/pending pull requests to make endpoints dynamic, not the issue)

It would be useful to document this so people wouldn't need to ask.

Further to this however is that I'm starting to work on some major refactoring of fog that may make master unstable.

So we can end up with the simple change (new endpoint) stuck behind an unstable change that needs full testing by all providers before we can consider a stable release. Or a new version of a provider's API.

So I think it's worth a discussion about how we should schedule future releases, relate them to branches and document that.

  • Do we offer a stable branch? 1.8_branch ?
  • Aim for even minor releases being stable (1.8) and odd (1.9) less so?
  • Issue Release Candidates so early adopters can help test without it getting picked up by bundler for most people?
  • Any projects we can learn from?

Some of the complexity disappears when fog goes modular and providers can version their own changes and fog is a stable snapshot of those versions, but it would be good to start somewhere.

So after a bit of discussion I'll add RELEASE.md to the project root with a write up. Who to speak to. Where to base changes. Which rake tasks to run.

Cheers!

Owner

geemus commented Dec 20, 2012

@tokengeek - sounds like a good start. I'm not sure where to land stability-wise. I prefer master to be stable and have major stuff in topic branches for the most part I think (gut reaction wise), but it is harder. Modularity definitely needs to happen, hoping to sneak some time toward this over the holiday, but we shall see.

Member

rubiojr commented Dec 20, 2012

Great stuff @tokengeek, thanks for sharing.

It would be great also to have some sort of policy to coordinate maintainers, so they have enough time to test for potential breaking changes in core before the next release, define release periods, etc.
Debian is probably one of the largest distributed projects in existence (some other distros too), and they usually have a good release policy documented and tools to coordinate that kind of stuff (besides mailing lists I believe). It think it applies to any large project, as the core issues are pretty much the same (integration, release docs and prep, etc). Ubuntu has pretty good release engineering documentation also.

+1 to keep master stable also, if only because many people just clone and try to run stuff from there, without looking at the branches. It's definitely a very personal opinion as other folks do have stable branches so...

I definitely like the stable (even) vs odd (development) versioning too, as well as the semver.org stuff.

+1 Pushing .rc versions to rubygems.org.

Having said that, I don't have any problem with the model you guys are following right now. Probably because I'm not involved in core and fog/core in master is pretty much rock solid all the time! Perhaps the google group should have a little bit more of traffic discussing this kind of stuff and coordinating releases, not sure.

Cheers!

Contributor

neillturner commented Dec 21, 2012

You may need to follow cloud foundry and openstack who use Gerrit to frontend the github repository and do code reviews and testing before pushing to master repository.

Also I think that parameters like regions needs way to add values external to the code to avoid these sort of changes.
For example you could allow an environment variable to be set say
export FOG_AWS_ADDITIONAL_REGION="ap-southeast-2"

and the code to validate region in fog also looks for the environment variable.

@ghost ghost assigned tokengeek Dec 24, 2012

Owner

tokengeek commented Dec 24, 2012

Would a rough schedule, a new release every nth Tuesday(?) a month, with a release candidate a week ahead be useful? At least for the time being.

So people have an expected date to work to.

Things change when we go modular since core would be stable, providers may be changing and fog would be mostly a changing gemspec.

I'd also vote for master remaining stable since it is good practice. So then it is how to coordinate all providers across experimental branches.

Deciding on where we announce releases is something we should cover here as well.

Owner

geemus commented Dec 25, 2012

nth day is probably alright, but probably not a weekday while I'm still doing it and we are not-so-modular (I can usually only find the time on weekends). Not sure about announcement and release candidates (I've never really used an rc and to some extent I feel like it will just double the number of releases I'll have to do and it is already burdensome).

Owner

tokengeek commented Dec 27, 2012

@geemus two things you mentioned that are important:

  • releasing is currently a burden
  • you're currently the only one who can do a release

I'll start on the RELEASE.md file based on what is currently done.

Ideally the release process should be rake release, perhaps with minimal manual sanity checks. I know that is not the case so we can work on the outstanding problems.

I'm sure there's a few of us that can help out on releases when we have sorted out things like live tests and all the credentials.

I'm not sure what the best release day would be verses work week/weekend. As you said, it's related to the burden of a doing a release.

I think the main advantage of release candidates is to help coordinate many providers and to ensure people using fog as a library aren't caught out in production settings. I seem to recall our CLI being broken twice due to fog changes but we dodged those bullets since we vendor fog.

Owner

geemus commented Dec 27, 2012

@tokengeek - sounds good, thanks for continuing to really be on top of this!

tokengeek added a commit that referenced this issue Dec 27, 2012

[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

tokengeek added a commit that referenced this issue Jan 7, 2013

[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
Owner

geemus commented Dec 19, 2013

Closing as this hasn't been touched in a year. If this was closed in error or is still an issue, please re-open. Thanks!

@geemus geemus closed this Dec 19, 2013

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