Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
This was done in an attempt to prevent the warning saying “This file is set to build for a version older than the project deployment target.”
Unfortunately saving all the xibs did not get rid of the warning, even though tehy are all set to have 10.7 as their build target.
The latest xib format does however remove about 10.000 lines of XML.
I mainly dislike the trailing zeroes because CGFloat used to be a float but 1.0 is a double (1.0f would be a float). So better to under-specify and let the compiler figure out the proper type.
The ‘lastVersionDownloaded’ property used ‘assign’ (since it used to be an integer) which meant TextMate would likely crash when the property was read (and had a non-nil value), which it would, when TextMate did a version check after already having downloaded an update (but not yet installed and relaunched).
Also drop the atomic requirement of the ‘archive’ property since we no longer access it from multiple threads.
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”.
We also add a time suffix to the old version so that if we fail to remove it, the user will not get (another) error when retrying the update.
Presumably fixes#991.
The “proper” replacement for this API is to use the ServiceManagement framework’s SMJobBless() to bless our helper tool. In two of the three use-cases our helper tool is however regular shell commands, so it seems redundant to wrap these shell tools as helper tools we can install as launchd jobs.
Initially ‘downloadWindow’ was a property that was nil until we showed the download window, but now that the download window is re-used for downloading newer versions (incase a newer version appear before user does the “Install & Relaunch”) the fetching the property will return the window (and create it if not already created).
This is instead of only showing the revision, which lack semantic info such as ‘alpha’ and 2.0 versus 1.5.11.
We now also show the version after a successful download instead of just “Download Completed”.
The user can manually disable session restore, which is undesired when relaunching due to a software update or installing a plug-in, so we now override the user’s choice for the new instance launched.
We now keep the root folder and instead replace the inner Contents folder — hopefully this way LaunchServices won’t add the update as a new entry (causing duplicates to show up in the Open With menu).
This should hopefully solve the issue with the (on some systems) fairly aggressive temp cleaner.
Also remove the archive incase the user cancels the update, now that we are extracting it to a less temporary location.
Presently mainly a semantic change, as the dispatch queues are mostly empty, but as we adopt GCD for more things, it’ll be more important to put background tasks in a queue with lower priority than the one handling user requested tasks.
A “Downgrade” button now appear if the version on the server is lower than the current one. This would e.g. happen if the user has upgraded to a nightly build and does a manual version check (for non-nightly builds).
If the version on the server is the same version as the one running, the user can make a “Redownload” button appear by holding down shift (⇧) when running the update check.
We now explicitly disable it for targets that hasn’t yet been upgraded to ARC. This way, it’s easier to get an overview of which targets hasn’t yet been upgraded and ensures new targets has ARC enabled.
