> Am 13.03.2011 um 05:17 schrieb Evan Schoenberg, M.D.: > >> 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. > > If we drop 10.5 support now how is that going to improve stability of 1.5hg? > > How can we make Trunk more stable, how can we get closer to a release of code > that has been in development for 1,5 years? Unless we find a dozen or so > interested and competent developers somewhere I believe the only to get there > is announcing a string-freeze (at least that's how it "works" for Pidgin and > rekkanoryo). > > On the contrary, opening the door for implementing code that deprecates 10.5 > might just mean it will take even longer to move 1.5 closer to release.
This argument (and not one that involves preventing certain users from upgrading) is the first against making a 10.6+ move which resonates with me. However, just releasing 1.5 isn't our only concern. If we're talking about a release which is the last 10.5 version, we want to leave it in as stable a condition as possible. Also, I'd like trunk to become a primary source of releases, with feature branches used for experimental and in-progress work. Maintaining two repositories (currently adium and adium-1.4) is time consuming to an extent that it is a barrier to production. When we release 1.5, there will be numerous regressions we don't find until it's in mass availability, regardless of our testing - years of experience have shown this... if 1.5 is 10.5+, and 1.6hg is 10.6+, we'll have increased difficulty in merging fixes, as described previously. 1.4.x is a really, really good release series. Adium is currently the best it has ever been. The biggest changes in 1.5 at this point are architectural -- and 64-bit support doesn't impact the 10.5 users anyways. The average 10.5-using user will find good work, yes, but nothing groundbreaking if she were to move from Adium 1.4.x to 1.5hg. We don't need blocks or GCD to get 1.5 out the door; we just need good old-fashioned time and care. However, after 1.5 is released, I would like 1.5.1 to be able to use such technology, brought in during its development phase as desired. If the 1.5 series is 10.5+, we're trapped with a continued trunk vs. release series dichotomy, and we've seen what happens... years go by before we're sufficiently stable after major changes to do a release. >> 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. > > To me, that is the strongest argument. However, it is somewhat damaged by > that the fact that Xcode 4 is very buggy. That and at the fact you need a > credit card to buy the 5$ app unless you're paying 100$ to Apple already, > will keep a good portion of possible new contributors using Xcode 3. And that's fine. Xcode 4 projects are backwards-compatible with Xcode 3. When we are Xcode 4 compatible, I will personally purchase a copy of Xcode 4 for any Adium developer who does not have one and for any potential contributor who emails me with a reasonably-well-thought out plan or intention (for a generous but reasonable number of contributors). It may be that we decide that with some criteria, the project will do that with donated funds... but that's neither here nor there and doesn't change my offer. > How are you going to gift something if you don't know who needs it? Not every > potential contributor is going to turn up in #adium-devl and say: "hey, I'd > like to contribute but I don't have 5$". So long as Xcode 3 remains free, they can use that. > Plus, BJ Homer wrote >> you can absolutely use the 10.6 SDK and run on Leopard (and thus Xcode 4 can >> be used without dropping Leopard) > >> 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. > > I thought we moved to a DVCS in the first place to allow this sort of > situation. Thijs for example has already set up a fork on Bitbucket working > on libdispatch support. The DVCS does make this much easier than it would be otherwise, but the fact remains that this becomes difficult with far-reaching changes. The libdispatch work is centralized on a single module (adiumPurpleEventLoop) which itself has been largely unchanged for many years... so it's a great candidate for a 'feature branch'. >> The outpouring of responses from developers in this thread shows the >> enthusiasm at being able to use modern tools and tech. > > This is what I've seen every time a new OS came around in the past few years > so I can't say I'm surprised. Developers will always be excited to use new > features and API . But in my opinion Adium should be more than a testing > field for new stuff Apple comes up with. I agree wholeheartedly with it being more than a testing field. Doesn't change my opinions above, though :) > >> 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. > > Based on the arguments I have given in this thread, I don't think keeping > 10.5 should leave out a large humber of developers. It doesn't leave them out in terms of making it impossible for them to contribute... but it does raise the barrier to contribution [must have Xcode 3 installed and use it] - both from potential new developers and (and this shouldn't be understated) from current contributors who choose on a day-to-day basis whether to load the Adium.xcodeproj and do a little hacking. > Naturally, my opposition (especially as a non-programming contributor) > shouldn't stop you guys doing what you think is best for the Adium Project > but I feel it is important to present a diverging perspective. Thank you for providing it. -Evan
