Dreamwidth Development

Hi all!

As of today, I've made a few fairly broad changes to the way our repositories are set up. You will need to likely make some changes to your development workflow. But! They should be simple.

First, the changes:

1. The dw-free repository has been renamed to dreamwidth -- because,

2. The dw-nonfree repository is no more, it has been merged into the dw-free under the path ext/dw-nonfree/.

3. Finally, the master branch has been renamed to main.

These two changes mean that no more do we have to track and coordinate changes across two repositories, they can be done atomically in one place. Since we don't really support or test running Dreamwidth on its own (without the branding) this will also allow us to simplify development by ultimately collapsing the code, too.

To update your checkout of Dreamwidth, you will need to do two separate things. First, go to Github and to your existing dw-free repository, go to the settings and:

1. Rename the repository to dreamwidth

2. Go to branches and rename the master branch to main

Once that's done, you need to update your local checkout like this:

 cd $LJHOME

 # WARNING: Only do this if you have no code here that you care about!
 rm -rf ext/dw-nonfree

 # Update the repository root (for your "origin" remote, **set your username here**)
 git remote set-url origin git@github.com:YOUR_GITHUB_USERNAME/dreamwidth.git

 # Update the repository root (for your "upstream" remote, please change as needed)
 git remote set-url upstream git@github.com:dreamwidth/dreamwidth.git

 # Fetch only to get the new main branch
 git fetch

 # Switch over to it
 git checkout main

 # Get rid of local master
 git branch -d master

 # Redirect HEAD
 git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

That's it; you should be good to go now. I'll work on updating the Dreamhack scripts shortly, but wanted to get these instructions out. Please let me know if you have any questions/comments/issues.

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 fu and exor674 (and others!) to make sure that everything was in place. fu put together a nice "things we have to do" in 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.