[gst-devel] branches

[David I. Lehn]

* Thomas Vander Stichele <thomas at urgent.rug.ac.be> [20030122 17:50]:
> a few of us have wondered how to do the branches from here on.
... 
> 1) branch a 0.6.0 branch off of the current 0.5.2 one.
>    after 0.6.0 is out, merge back to HEAD.
>    HEAD becomes the "stable" series, only bug fixes allowed
>    at some point in the future (but not right now) a 0.7 branch gets
>    made in which people can mess up again :)
> 
> 2) branch 0.6.0 off 0.5.2
>    when 0.6.0 is out, update HEAD to 0.7.0.1 and make that the dev series
>    right away
>    branch a 0.6.x branch off of 0.6.0
>    track bug fixes in this branch
> 
> 
> Reasons for choosing 1) would be
>  - "stable" is the one that people will check out most likely,
>    so people get a stable gstreamer and more people are inclined to 
>    actually use it and fix stuff in it

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.


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


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


> Reasons for choosing 2) would be
>  - no need to hold off some development
> 
> I'm personally inclined towards 1), because that means people will more 
> likely make sure stable works well.  I think it's better to keep our good 
> coders and bugfixers focused on HEAD :)
> 

I seriously doubt anyone's ability to herd cats.  Certainly we all want
to have a nice stable API/ABI for people to use.  But GStreamer is still
very young and I think we still need to let the dev code and coders
wander where they will.

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.

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

- i sort of assumed that's how it would be done ;)
- everyone else does dev work in HEAD:
  - glib/gtk (i think?)
  - http://www.xfree86.org/cvs/
  - I'm pretty sure mozilla does, ie, see their roadmap graphic:
    http://www.mozilla.org/roadmap.html
- HEAD is usually though of as the appropriate place for the future
  coding vector, ie, goes to forever
- branches are thought of as ending, ie 0.6.0 only lasts for so long
  then won't grow out anymore
- it's a longer term (post 0.7) methodology
- we can be informal for a while and just not break stuff in HEAD too
  much so that patches back to 0.6 branch are not too difficult.

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.

-dave