But working with cutting edge specifications that are still under development means that I do get to deal with incompatibilities with things that no one else is really aware of. In my case I am using the W3C Web Storage spec heavily for my work. If you are not familiar with the spec it specifies a key/value store, both a persistent store and one that is only valid while the web page is loaded -- and a SQL store. I am only using the key/value store as there is talk of dropping the SQL store so as to not have to deal with specifying SQL for the browser.
It turns out that both Firefox 3.5 and Safari 4 do not follow the spec exactly. Both browsers raise an exception in a case where the spec clearly says null is to be returned. And Firefox 3.5 has an extra incompatibility where it does not coerce key and value arguments to strings, e.g. coerce null to "null".
Because of these incompatibilities, both against the spec and each other, I have started a new open source project called realStorage. Version 1.0.0 provides a compatibility wrapper around localStorage so that (at least) Firefox 3.5 and Safari 4 act the same. Version 1.1 will get some non-standard functions that I have found useful in my PhD work.
One interesting thing (at least to me) that I am trying with this project is how to handle versions within an hg repository. I am trying out the approach that has been discussed for Python: named branches for minor versions with tags for each micro versions. A nice thing about this is that I can have people clone the repository with a specific version in the URL to always stay as up-to-date and cutting edge as they want. So people can clone https://realstorage.googlecode.com/hg/#1.0 and get the latest 1.0.x release. Or they could clone #1.0.0 if they want the exact code I released (unminified) along with the history. Or you can simply drop the specific revision and work from the default branch directly (which should be stable as I don't push to the repo until I am happy with the code). I suspect cloning o a specific tag or branch will become more popular as the use of sub-repositories in Mercurial picks up and people begin to want the most stable minor version of some library.
