mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Mark Smith ([staff profile] mark) wrote in [site community profile] dw_dev2012-09-22 09:49 pm
  • Add Memory
  • Share This Entry
Entry tags:

Release notes

We did our first release from git tonight. It went well, I will chalk that up to all of the hard work from folks like [personal profile] fu and [personal profile] exor674 (and others!) to make sure that everything was in place. [personal profile] fu put together a nice "things we have to do" in [site community profile] dw_staff, so that was very helpful.

Anyway, I wanted to document some things that are important to know for the period between releases. This probably won't apply to most of you, but just in case...

So, we are following the document about a successful git branching model. This is what git flow is based on and it's a really efficient model, so we're using it for doing our features and in this case, our release.

The release process was, in essence:

  • Create a release-1.11.0 branch
  • Make final tweaks in this branch to get things ready for release
  • Push this branch live
  • Merge this branch back in to develop and master
  • Add a release tag with the version number on master

This leaves our repository in this state:

  • develop is still open, you can keep committing things to it (no code freeze, yay!)
  • master has stable tags, so you can always roll back to tags here (easy production rolls!)
  • release-1.11.0 is open for doing fixes on the live release (easy fixing production, yay!)

The thing that is important to know, if you are going to be committing fixes that you intend to go live, is that you need to make your changes on the release-x.xx.x branch -- not on develop. Any code committed to develop will, because of its nature, have to wait until the next code push -- weeks away.

If you have stuff you need to get live sooner (fixes to things broken in the last code push or stability/important fixes), you need to adjust your workflow slightly. It's pretty easy though, and goes something like this:

git checkout -b release-1.11.0 dreamwidth/release-1.11.0

Now make your fixes, as per normal, and submit a pull request. As long as your current branch is the release branch, then you will be able to submit a pull request on the appropriate branch, and we can merge it in and push it out to the site quite easily.

Flat | Top-Level Comments Only
ninetydegrees: Text: let's make better mistakes tomorrow. (mistakes)

[personal profile] ninetydegrees 2012-09-23 09:02 pm (UTC)(link)
For the record, I was always in develop (I check before I do anything) but I'll try this.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

[staff profile] mark 2012-09-23 09:07 pm (UTC)(link)
Okay.

git pull dreamwidth develop:develop
git pull dreamwidth master:master

That will merge "develop" into whatever branch you're on. Then it will merge "master" into whatever branch you're on. It doesn't matter where you are -- that particular set of steps will screw up your repositories and then immediately push it up to GitHub, causing all sorts of trouble.

The only reason this ever worked is because we branched develop and then never touched master -- so it worked if someone was always in develop (like you) -- until yesterday, when I updated master. (And the only reason it worked to begin with is because master was an exact subset of develop, down to the ordering and everything.)

When [personal profile] yvi had a problem, it was because she was in master, so it pulled develop over that way.

TMYK, I suppose.
ninetydegrees: Art: self-portrait (Default)

[personal profile] ninetydegrees 2012-09-23 09:09 pm (UTC)(link)
Okayyyyyyyyyy. That makes sense. Sorry I'm so slow! ;)
Flat | Top-Level Comments Only