This all sounds sensible to me. To summarize the case for dropping 10.5: - Developers are all in favor of dropping 10.5 ASAP, from a personal perspective. - In addition, delaying in dropping 10.5 will make our release and new contributor processes substantially more complicated. - Finally, 1.4.x can continue to be updated for the foreseeable future to ensure connectivity for the users we are leaving behind.
I motion that we make the change in 1.5hg ASAP, unless anyone has any new objections or sees any flaws in the above. (One suggestion, re: release schedules. It would be great if we could get automated messages sent to this list about the different phases as the happen, and also if there was a way to get that info into iCal as well. I'm willing to help if someone has (simple) ideas as for how.) -Colin (via thumbs) On Mar 12, 2011, at 7:17 PM, "Evan Schoenberg, M.D." <eva...@dreskin.net> wrote: > > On Mar 12, 2011, at 7:10 AM, Robert Vehse wrote: > >> >> Am 12.03.2011 um 06:51 schrieb Christopher Forsythe: >> >>> I think it's unrealistic to force volunteers to do things that make their >>> lives harder. >>> >>> If I have a vote, for this. >>> >>> Chris >> >> Killer phrase, heh. Let's drop 10.6 support then right away since >> everybody's going crazy about Xcode 4 and 10.7 and having to support >> anything older is just bothersome. And while we're at it, let's just drop >> support for all services except XMPP (and perhaps AIM) since nobody cares >> about the others... >> >> Nobody has really countered my argument that it is well likely we might >> release 1.5 before Lion is out. Following what we agreed on in a previous >> meeting (http://trac.adium.im/wiki/ReleaseCycle) we should soon wrap up 1.5. >> It has been in development for 1,5 years. I can't see how dropping 10.5 >> support that late in the cycle can have so much merit. > > The fact of the matter is that were to release 1.5 right now, we'd have a > huge mess on our hands. It's unstable. We should be in internal_converge_2 > right now, but I just don't see that being a 1 month process prior to release. > > On one hand, if merges were Really Easy even with large changes, I would > propose the following. I thought this possibility through prior to my initial > email in this thread: > 1. Continue work on fb-xmpp for Adium 1.4.2. > 2. Merge this when complete to Adium 1.5. > 3. Feature-freeze Adium 1.5. > 4. Converge; and prepare for beta > 5. Branch when 1.5b1 is released. Expect minimal 1.5.x releases, as we have > with 1.4. > 6. Trunk becomes 1.6hg, which is 10.6+. > > The problem with this series of steps is that Apple has dealt a hand to > developers in which supporting 10.5 – or supporting PPC – means using > outdated tools and technology. Until step 6 is done, anyone who chooses to > install the primary distribution of Xcode is unable to contribute to Adium > (or even to build from source). We have to ask any potential contributor to > download a 4.4 GB installer (xcode 3.2.6) and install the 11.9 GB > distribution as a simple prerequisite to participating. > > Large feature branches are only sustainable if the trunk from which they > branched stays grossly similar. If we were to branch 1.5 at this point > (maintaining, for a time, adium-1.4, adium-1.5, and adium which would be > 1.6hg), we'd end up with increasingly complex merges as 1.5 and 1.6 rapidly > diverged. > > The outpouring of responses from developers in this thread shows the > enthusiasm at being able to use modern tools and tech. > > So I don't think the steps above are appropriate. I think that we should > move with the times. That means 10.6+ and Intel-only. > > This leaves out a number of users. I wish it didn't, but the alternative is > leaving out a number of developers... which in turn would mean less for the > larger number of users to use and enjoy. > > Paul Wilde asked: >> I think the most important question to ask though is how long (if at all) >> would the 1.4 branch be maintained for connection breakages for 10.5 users? > Since the 1.4 branch has a fairly sophisticated libpurple build system > (though not as excellent as 1.5's system), it shouldn't be difficult to > continue to provide periodic updates to the 1.4.x series, updating just > libpurple and related code {which is typically minimal in scope of changes > needed for updates, as libpurple's API is quite stable}. This is > particularly important if we're dropping a whole architecture, too. > > -Evan
