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
