At what point do we cut off? I expect at some point not all the
dependencies will even be buildable on the system. The only way I can
see supporting a lot of versions is if it's fairly automated process.
Right now there seems to be quite a bit of work by hand to keep things
all in step. Or do we drop it off once the number of worldwide users is
below a certain limit?
Linux is the same way, Ubuntu 10.04 is about to get dropped out of new
releases(if it isn't already when 14.04 comes out) and it is newer than
OS X 10.6
Of course Mac users have another issue, because of hardware OS X 10.6
might be the highest they can ever go with OS X. Which only leaves one
option (faced by many people with computers), do I buy new hardware or
switch to recent linux and get another 5 years+ out of the machine with
security patches and software upgrades. I guess technically there should
be people with 3 year old machines that came with 10.6, so at least
another 2-4 years of security patches from Apple.
Maybe someone has a spare 10.6 machine and wants to learn from William
how to make the builds on it?
Building on OS X isn't hard, just tedious. The build instructions are very detailed, so anyone should be able to roll their own if needed on an older system. The last Qt 4.8.5 installer works on 10.6, and dependencies should be buildable on 10.6 for a long time.
There are also OS X package managers to simplify the process. I think MacPorts is still alive, and Homebrew has become very popular. (Though they can cause trouble if you also compile software from scratch outside their environments.)
Note: if you read my blog about it, in my interpretation of the hardware maintenance it's the hardware that Apple supports, and it's the latest version of the system software that the hardware supports that is maintained, not the original version of the system. So 10.6 is dead now. Which has been verified in the latest security update that was for 10.7+.
I've mentioned my policy in the past and have been following it for years. It's just hitting a little hard this time because of the long life Snow Leopard had.
On Mar 7, 2014, at 10:23 PM, Alex Mandel wrote:
> It's a tricky problem, somewhat related to number of users
> http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0&qptimeframe=Y > 10.6 share has been declining 20% over the last year (relative to itself).
> At what point do we cut off? I expect at some point not all the
> dependencies will even be buildable on the system. The only way I can
> see supporting a lot of versions is if it's fairly automated process.
> Right now there seems to be quite a bit of work by hand to keep things
> all in step. Or do we drop it off once the number of worldwide users is
> below a certain limit?
> Linux is the same way, Ubuntu 10.04 is about to get dropped out of new
> releases(if it isn't already when 14.04 comes out) and it is newer than
> OS X 10.6
> Of course Mac users have another issue, because of hardware OS X 10.6
> might be the highest they can ever go with OS X. Which only leaves one
> option (faced by many people with computers), do I buy new hardware or
> switch to recent linux and get another 5 years+ out of the machine with
> security patches and software upgrades. I guess technically there should
> be people with 3 year old machines that came with 10.6, so at least
> another 2-4 years of security patches from Apple.
> Maybe someone has a spare 10.6 machine and wants to learn from William
> how to make the builds on it?
> On 03/07/2014 03:54 PM, Etienne Tourigny wrote:
>> Maybe it's time to find sponsors for hosted environments to build qgis on
>> On Fri, Mar 7, 2014 at 11:46 AM, Richard Duivenvoorde
>> <[hidden email]>wrote:
>>> On 07-03-14 15:16, Joris HINTJENS wrote:
>>>> Hi there,
>>>> Just upgraded my Imac to OS 10.6
>>>> Any chance to find someday an installerpackage QGIS2.2 for my OS?
>>>> For now, "the computer says noo!"
>>> Installers are provided by William. This is what he says about 10.6:
>>> http://www.kyngchaos.com/blog/2014/20140223_snow_leopard_support_ending >>>
>>> Richard Duivenvoorde
>>> Qgis-user mailing list
>>> [hidden email] >>> http://lists.osgeo.org/mailman/listinfo/qgis-user >
> Qgis-user mailing list
> [hidden email] > http://lists.osgeo.org/mailman/listinfo/qgis-user
While this is true, both the 10.7+ and 1.0.6 nightlies are currently built against William's frameworks. In the event his supporting frameworks will not install for 10.6, that nightly will be suspended. The nightlies are very 'bare bones' for running unit test suites and for testers to help debug the core application. They are a far cry from the out-of-the-box, heavily bundled installers from William, and the nightlies should not be considered, or recommended, as a production tool.
On the brighter side, the OSGeo4Mac project  (a 'tap' for Homebrew) is coming along nicely, with about a 90% feature parity with William's framework builds. I have not tested a full build (QGIS and Processing supporting installs) under 10.6 yet, but it looks like I should do this ASAP. If anyone knows how to use Homebrew, they can give it a try themselves, basically without having to read QGIS's INSTALL doc.
These are the pending changes that will affect future nightlies:
1) Move to using OSGeo4Mac as the basis for 10.6 and 10.7+ nightly builds
2) Continue an additional 10.7+ nightly built off of William's frameworks
3) Add new modules to QGIS (in parallel to current) to leverage CMake's built-in bundling utilities
4) Implement pull request #1804: Add objective-c++ interface to Mac Cocoa libraries 
5) Add Sparkle framework (hopefully goes well) to allow for in-app, auto-download/install updates
Reasoning for these steps:
1) Since Homebrew offers support for 'bottled' builds (pre-built binaries), the nightly 'downloads' can be just moved to bottles, and Homebrew can automate their installation. Such bottles, especially for supporting libs, can also be used to sustain a Travis (or possibly Jenkins) continuous integration server .
The Homebrew setup offers an additional testing facet to nightlies: testers can readily build and use the latest versions of supporting libs, like GDAL, to test against the latest QGIS. This will help the QGIS project stay ahead of possible incompatibility issues.
2) Since William's installers are so mature, widely-used and known, it makes sense to continue to offer nightlies for testers that don't want to (or can't) compile anything. This helps debug releases and subsequent fixes, and makes it as simple as possible for users to work with a nightly. However, this setup requires the most bandwidth, which is another reason why I'll be dropping it for 10.6.
3) CMake's BundleUtilites [3, 4] are considerably more mature now than when William tackled the large effort of creating QGIS's current bundling setup. Leveraging CMake's toolset will allow for quicker adoption of bundling ever more Processing supporting libs/executables and allow to future-proof complete bundling of QGIS off of the OSGeo4Mac installation (as well as others).
4) and 5) An embedded auto-updater will allow for testers to just launch QGIS and choose to download and auto-install the latest nightly, regardless of its build backend or supporting lib setup. This will also test the auto-updater itself, which, when found to be stable, can be incorporated into release versions.
I do all of this nightly build stuff on borrowed CPU time and disk space from my gracious employer. It would be really nice to do this on hardware provided by the QGIS project or OSGeo, but this means purchasing at least one highend Mac, since legally virtualizing or installing any Mac OS X requires Mac hardware. A minimum of 4 (ideally 8) CPU cores would be necessary.
Anyone have $1000-1200 USD they can donate to the QGIS project, for their very own decent Mac Mini? (That would include AppleCare.) I'd donate my time and know-how.