[Adium-devl] 1.2 ?!?

[Colin Barrett]

First off, well said.
On Dec 25, 2007,
  at 12:57 PM, Evan Schoenberg wrote:

> 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'.

IMO micro releases shouldn't contain any "features", just bug fixes,  
and to solve the log-jam problem you describe, we should release more  
often.

> 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.

+1 to the doubling up suggestion. I also think that having six  
completely divergent branches was a mistake. I'd love it if students  
could work normally, either on trunk or in much more shortlived  
branches that get merged to trunk more often. I think a dvcs would  
make that easier, as well.

> 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.

I agree, and I don't really have any answer except that you can't  
have the very open, unstructured process we currently have an  
increase our code quality. You have to increase structure to improve  
quality. Period.

>  * 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.

Honestly, I don't think it really matters which DVCS we use, as long  
as we're using *something*.

> 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.

I think the real issue here is that the version numbers for Adium  
have no meaning at all. Perhaps only bug and security fixes are micro  
releases, everything else gets a major version number bump? I think  
our trac hurts us in this case, it's easy to put things into, for  
example, the "1.3" bucket and then we get these huge releases.  
Perhaps using priority or a flag or different milestones ("maybe next  
release"?) to help us identify which issues are the critical ones for  
this release will help.

I hope to clear a few infra things off my plate this week and  
actually get back to being able to do Adium development in my free  
time. Oh how I hope that's true. ;)

-Colin


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