First post from iPhone

July 22, 2008

Yep, I’ve got an iPhone. While I was in the US, I was offered for a fair price a used 1st gen model from somebody who bought the 3G. Since I did not obtain the phone as part of a contract or under any other restrictions, I happily installed a modified bootloader which activated the device and removed the SIM lock (all thanks to PwnageTool 2.0). So now I can enjoy this brilliant machine with my economical pre-paid plan (Simyo). German T-Mobile’s iPhone plans just don’t work for me (which is why I hadn’t bothered to buy one yet).

After playing around with it, here are some observations:

- how do I create bullet lists in this WordPress client?

- sometimes apps aren’t as snappy as you’d think they would be. For instance, it takes quite a long time for the Addressbook to finish loading.

- the UI is quite refined, as you’d expect from apple. Not only that, you can really tell that the engineers thought it all the way through: the little keyboard and its auto-correction, for instance, let me achieve good typing speed. Certainly nothing you’d imagine on a device as small as this. I also love how navigation works so intuitively, e.g how long alphabetical lists have a teeny A-Z index on the side. Tap your finger on a letter and the list jumps to that letter. You’d think the letters are too small for that to work reliably. But it just works.

- I haven’t gotten GPRS to work yet. So for now I have to rely on WiFi for Internet connectivity. Phone works well though.

- the battery life doesn’t seem to be all that great.

- I feel uncomfortable storing various passwords (which for instance the mail client requires) on a mobile device that’s easily lost.

- shazam rocks :)

The release process that I wrote for the Zope subversion repository states that a library’s version number on the trunk or a release branch should always be the next release version number applicable to that branch. For instance, if zope.interface 3.4.1 were just released from the 3.4.x branch, the version number of zope.interface on that branch should read 3.4.2dev.

Let me explain why I suggested this practice and, despite much critique, still maintain it’s makes the most sense.

First of all, the setuptools documentation states:

Note: the project version number you specify in setup.py should always be the next version of your software, not the last released version.

So it’s a convention that seems to be generally suggested. That doesn’t necessarily mean it’s a good idea, though.

What makes it a good idea is the fact that when you get a checkout of the trunk or a development branch, the version number is actually meaningful, due to setuptools’ version semantics

3.4.1 < 3.4.2dev < 3.4.2

So, a development egg of zope.interface 3.4.2dev will for instance satisfy a version requirement like “zope.interface > 3.4.1“. For example, say you wanted to temporarily deploy from a subversion checkout. I had to do this to get my PyFlakes running with Emacs. The latest release PyFlakes 0.2.1 wasn’t good enough because something got fixed on the trunk. So I got a trunk checkout and did a

python setup.py install

into a virtualenv. Surely enough, the trunk’s version number was still pointing to 0.2.1. So I ended up with pyflakes-0.2.1-py2.4.egg in my site-packages and no way to tell it from the actual 0.2.1 release. (Yes, I know there’s some setuptools parameter than can let you build versions like 0.2.1-r48292, and those would be fine, if they were configured to occur on the trunk automatically.) So that’s why not only bumping the version number to the next release but also adding the “dev” marker to tell development eggs or snapshots apart from actual release (and prevent people from releasing from the trunk!) is a good idea.

To conclude, I think bumping the version number to the next or at least the next anticipated release (it’s ok if you don’t get the version number right the first time) and adding a dev marker is not only a good idea, I think it’s pretty much the only way to get the version number semantics of development eggs right (unless you use r34234 suffixes which have other problems). Of course, I’m willing to be convinced otherwise if alternate solutions achieve the same semantics. Comment away!

Follow

Get every new post delivered to your Inbox.