Time-based releases and love

I believe in time-based releases. I believe in frequent releases. I believe in a trunk branch that is always ready to be a release candidate. Many Free Software developers share my beliefs. For a long time I haven't questioned it. It's obviously good to release regularly and often.

"It is hard to argue that bzr isn't in a state of flux when a new stable version is available once a month." - Jason Earl, Bazaar mailing list.

Now I think I have to begin asking questions.

Is it possible that time-based releases actually create negative impressions of software? Should regular releasers slow down their cadence? How should compatibility watersheds (format, API, whatever) affect a release cycle? What would Bazaar's format reputation be like if they released every six months instead of every month?

brisbane-core

Up in Brisbane, while I was diligently working away on package branches in Launchpad, many of the Bazaar guys were working on their new "brisbane-core" format.

I overheard one of them say in this new format 'log -v' is up to twenty times faster.

Want more details? Well, perhaps someone else on Planet Bazaar can provide them.

Another Bazaar story

I'm currently hacking away on Launchpad's support for "stacked branches", something that will really make Launchpad's codehosting a joy to use.

At the moment, I'm writing some tests that require a user to login. This was becoming a bit cumbersome, until I remembered something: Tim has recently landed some code to make this easy. But how do I get these changes without messing up all of the work I'm doing now? bzr shelve to the rescue!

'shelve' interactively goes through each change you've made to your current working tree and allows you to decide whether to keep a change or shelve it. It comes with a twin command 'unshelve', which lets you interactively restore your changes.

In this case, I don't even care about the interactivity, so here's what I did:

# Shelve my changes
bzr shelve --all
# Fetch the latest trunk
cd ../trunk
bzr pull
# Merge it into my branch
cd ../stacking
bzr merge ../trunk
bzr ci -m "Merge in changes from trunk to get login testing improvements."
# Restore my changes
bzr unshelve --all

The 'shelve' command comes with the bzrtools plugin, and I am basically in love with it.

As a parting shot, I should mention that things like bzrtools aren't accidents. They are natural and inevitable when you have good APIs in a high-level language and a very nice plugin system.

And now I'm off to keep working on this branch.

User Experience — When Reality Attacks

I've just got back from a hectic week in London, where members of the Bazaar community got together and thrashed out a bunch of important topics.

We talked about "user experience" and how we all want Bazaar to be a joy to use. More than one person said that we have been focusing too much on features and performance instead of user experience. The term was never really pinned down, but it's fair to say that there are things other than convenience and speed that affect how users feel while using Bazaar and that we need to work on those things, once we figure out what they are.

I think I might know the name of one of them: errors. Next post: "Notes on error".