Reinstate Snow Leopard compatibility about objective-git

[joshaber]

With 10.9 around the corner, I don't think it's worthwhile to support 10.6.

[rowanj]

I'd love to think that were the case, but my users disagree. I'll try to gather direct stats in my next release, but the recent data I can find suggests that Snow Leopard is still hovering around 30% adoption - a bit more than 10.7, a bit less than 10.8.

http://appleinsider.com/articles/13/01/04/os-x-108-mountain-lion-overtakes-107-lion-internet-share-for-first-time

http://www.adium.im/sparkle/#osVersion

http://chitika.com/os-x-version-distribution

[jspahrsummers]

Apple's approach is generally to support the last two major releases, which is what we're following here. There are significant API changes between 10.6 and 10.7 that make this more effort than it's worth (for us) – including the addition of weak references, which help avoid many kinds of memory management crashes.

We simply aren't able to commit to it – however, you're more than welcome to reinstate 10.6 support in a fork. Our official support isn't necessary for that, and that way you can still keep your users happy. :)

[rowanj]

I've considered preserving it in a fork; I already have one that I've submitted a few pull requests from; but the likelihood of conflicts with any given update when one side uses different storage attributes/polices and memory management rapidly approaches 1 - along with bugs due to mistranslated management affecting both old and new deployment platforms alike (especially as changes to Objective-C storage attributes affect only code generated in the interface that declares them).

10.9 will most likely be announced at WWDC, but given that it isn't even in developer preview yet, I still consider 10.6.8 to be solidly within two releases for the time being.

Unfortunately, while I understand that dropping support is the lowest cost to your team; this compatibility change leaves downstream maintainers like me with several options with varying degrees of features and correctness vs. time spent, and time is really the premium commodity in OSS projects.

Also, is there any announcements list or similar where I can be notified of stuff like this changing? Xcode doesn't check the deployment target of linked frameworks, so my first warning of this was user-reported crashes; and I feel like changing the supported platforms is kind of a bigger deal than the commit log made it out to be.

[kubark42]

Many of the people I know using Macs for non-OSX development are still using 10.6.8 because they don't care for the iphone-ization of the UI in 10.7 and 10.8. This isn't a reason for objective-git to change it's mind, just my anecdotal two cents about why 10.6.8 users might still make up a large number of downstream users.

[jspahrsummers]

the likelihood of conflicts with any given update when one side uses different storage attributes/polices and memory management rapidly approaches 1 - along with bugs due to mistranslated management affecting both old and new deployment platforms alike

@rowanj Certainly true. It's a trade-off, like everything else, but weak is just such a ridiculous win that it'd be hard to justify spending the effort on properly zeroing unsafe_unretained references. :\

10.9 will most likely be announced at WWDC, but given that it isn't even in developer preview yet, I still consider 10.6.8 to be solidly within two releases for the time being.

Ah, sorry, I meant 10.8 and 10.7 as the last two releases. AFAIK, these are the platforms that Apple currently supports with security updates.

this compatibility change leaves downstream maintainers like me with several options with varying degrees of features and correctness vs. time spent, and time is really the premium commodity in OSS projects.

I hear you – it's an unfortunate position for both of us to be in. This is also an OSS project for us, and the potential stability and correctness improvements are too great for us to ignore.

Also, is there any announcements list or similar where I can be notified of stuff like this changing?

Nothing outside of the repository, but notifications for pull requests would include stuff like this.

I feel like changing the supported platforms is kind of a bigger deal than the commit log made it out to be.

Yeah, sorry – this was poorly communicated. At the very least, we need to update the README with the supported platforms.

Many of the people I know using Macs for non-OSX development are still using 10.6.8 because they don't care for the iphone-ization of the UI in 10.7 and 10.8.

@kubark42 No doubt, but (I know this wasn't necessarily your personal position) that seems unlikely to change, and continuing to use 10.6 isn't going to prevent the platform from moving forward.

[stepheneb]

FYI: I use both 10.6.8 and 10.8.x everyday as development platforms (and also use rowanj's GitX fork all the time).

I continue to use 10.6.8 for two reasons. Some of my development is in Java and I need to be able to run and test using older JVMs (Java 1.6). Secondly there are a few PPC programs I still use and 10.6 is the last OS that supported execution of PPC programs via Rosetta (I know ... this is playing in the garden of seriously trailing edge technology ;-)

I would prefer that you continue to support 10.6 ... but can understand why you have dropped support.

[dannygreg]

I don't think it's all that productive for this thread to turn into a list of reasons why people are using 10.6. We dropped support based on our userbase numbers (where 10.6 use was a tiny minority). 10.7 gives us way too many development wins to hang around supporting 10.6.

All that said, this is open source, we aren't going to stop anyone maintaining a fork with 10.6 support 😄.