[Adium-devl] 1.2 ?!?

[Evan Schoenberg]

On Dec 25, 2007, at 4:03 PM, Colin Barrett wrote:

> On Dec 25, 2007, at 11:32 AM, Evan Schoenberg wrote:
>
>> Trust our upstream friends a bit. A minor release of Adium - our
>> changes - could carry a major libpurple upgrade -the Pidgin team's
>> changes.   We're all on the same team in a broader sense, but the
>> separation of powers affords us fantastic benefits.
>
> I still don't understand why a minor release of Adium should have a
> major release of libpurple in it. I trust the pidgin folks, but it
> still makes little sense to take such large changes in dot releases.
>
> I have never understood why our micro releases are so huge, but I'm
> not doing the releasing so I guess it's not up to me.

Well, there a couple of problems at work.

This idea of a micro release containing only micro features, while all  
major feature work takes place on trunk, is part of the problem. We  
end up with all major new features or fixes lumped into a single  
'trunk', which ends up nearly-permanently blocking release of the  
'next major version'.

On the other hand, Adium 1.1 and 1.2 were both really Summer of Code  
driven, and that was also a mistake in some way... but I don't know  
how else it could be handled.  Take a single person - no matter how  
dedicated or bright - and have them hack for a summer, with minimal  
supervision or code review or testing by third parties, and then  
arbitrarily merge all those changes and you get a significant problem.

We need to set clearer limits on how much a version should carry, and  
part of that requires releasing more often with major, non-self- 
contained/finished work taking place on microbranches.
  * This means returning to a previous thread which was never really  
brought to a conclusion: scheduling and limiting releases.  I don't  
know if there's a good answer in context of such limited coding  
manpower for the project, but we should seek to find one.
  * Augie, you've been a proponent of subversion 1.5 in the past.   
Could you brief us, in a new thread, on how branching & merging is  
best accomplished using that?  I'm wholly enamored of monotone at this  
point, 99% for its branch & propagate model which requires no tracking  
by its users.

On a final note: A release of libpurple by itself is reason enough for  
an Adium release, typically.  This goes hand-in-hand with being okay  
with small changesets for Adium releases.  I'm as guilty as anyone  
(guiltier?) when it comes to loving the sight of an impressive  
changeset, but delaying rolling out improvements to the world doesn't  
help anyone.
Also, Major/minor determinations at the libpurple level speak only to  
the API changes, not to protocol-level features or bug fixes, so  
matching major/minor to Adium major/minor seems silly.

Cheers,
Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20071225/8b9cc222/attachment-0001.html>