[gst-devel] branches

[Thomas Vander Stichele]

Hey,

> Hmm.. I would have thought people using CVS would be looking to see the
> latest and greatest code and would assume that was in HEAD.

Maybe :) development branches for specific features are also done off 
head, and there are always people who assume that HEAD builds as well. :)

> >  - "development" can be a little less strict; tree doesn't need to 
> >    strictly  always work well
> 
> That argument holds for whereever the dev tree is, HEAD or a branch.

True, if we make it clear to people that HEAD is the breaks-a-lot branch.

> >  - postponing a dev branch has the bonus of making a merge back easier at
> >    the end of the stable series
> 
> Do we need to be so strict?  We can just be informal about it and ask
> that no one breaks the API/ABI for a while.  If someone does then just
> revert those changes. (and throw patch in bugzilla for latter apply)
> 
> Merging suckiness is more related to what changes people start making.
> If you avoid people putting them in HEAD just due to policy then various
> peoples private trees will diverge and merging later will suck even more
> for everyone.

Merging suckiness can also come from the following situations:
- doing whitespace fixes
- doing doc fixes
- doing code rearranging
- doing refactoring

and probably others, I'm not that experienced with interbranch 
development.

Anyway, I assume there must be some easy way to apply a commit/patch to 
both branches at once, so we can keep the obvious patches (cleanups, doc 
fixes, ...) in sync between two branches ?

The goal is to basically minimise differences between the two branches, so 
that it becomes apparent where the changes are in code that does matter.

> If we actually get (m)any new applications based on stable code I'm sure
> they will find issues that may need to be addressed in a non-stable
> series.  We can merge bug fixes and so on between 0.6 and 0.7 as needed.
> It's of course going to start to suck at some point as the code diverges.

Right, which is what I'm not that experienced with, so I trust all of 
your's judgment.

> I vote 2 (branch for 0.6.0, dev in HEAD now):

> - HEAD is usually though of as the appropriate place for the future
>   coding vector, ie, goes to forever

yeah, good point.

> One issue is calling HEAD 0.7.0.1?  That means the first release of dev
> series will be 0.7.1?  Perhaps have a informal tagging of 0.6.0 code as
> 0.7.0 code too.  not really a release but just so versions make sense.

a minor problem, will be some time before we release one anyway.


Ok, since people are in favour of the second one, I've started branching 
that way.  Will send a mail on it later to here and gnome-desktop and 
gnome-multimedia


Thomas

 -- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Is there a voice unkind
in the back of your mind
saying "maybe you didn't know him at all"
<-*- thomas  (at) apestaart (dot) org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/