Checkin release notes
Handle creating a new bundle with name of existing bundle

Previously we would ensure that /path/to/info.plist inside the bundle was unique when we should have ensured that the actual bundle name was unique.
Resolve path for a bundle item after it has been created

We may save to a symlinked path but generally always work with resolved paths (for cache lookups, fs-events, etc.).
Deleting a bundle would only delete the contained info.plist
Invalidate bundle item (disk) cache when saving in bundle editor

Normally the cache is automatically invalidated via fs-events, but that is sadly unreliable.

Should fix #1034.
Add code for comparing complex version strings
Trim version string received from server
Use complex version string during software update checks

While it is simpler to compare a monotonically increasing integer (the revision), we always use the semantic version string in the user interface, meaning that this version string should change together with the revision, which effectively means we are maintaing two version numbers.

We previously embedded the revision in the version string (2.0-alpha.$revision) but when going from alpha → beta, it would be nice to reset the visible counter, so that first beta becomes 2.0-beta.1, furthermore, test versions could benefit from a more descriptive version string, e.g. “2.0-alpha.9439.2+debug” would be the second (semi-public) debug build after “2.0-alpha.9439”.
Remove revision field from version_info_t
Do not resolve broken symbolic links

Links that would point “above” the root (e.g. ‘/foo’ → ‘../../bar’) would cause an infinite recursion and eventually crash.
Use weak pointer for block-accessed run loop

I am seeing some crashes related to this code. My best guess is that a command execution (with exit handler) is created and then cancelled from JavaScript, which would invoke the cleanup block that uses the (now destroyed, but non-nilled) run loop.