Sep. 22nd, 2012

mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
[staff profile] mark

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.

Profile

dw_dev: The word "develop" using the Swirly D logo.  (Default)
Dreamwidth Open Source Development

June 2025

S M T W T F S
1234567
89101112 1314
15161718192021
22232425262728
2930     

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 11th, 2025 01:33 am
Powered by Dreamwidth Studios