[vlc-devel] Base for VLC ports (was Re: bluray: Add support for overlay)
remi at remlab.net
Thu Mar 8 19:34:00 CET 2012
Le jeudi 8 mars 2012 19:43:39 Jean-Baptiste Kempf, vous avez écrit :
> On Thu, Mar 08, 2012 at 12:39:51PM -0500, Rafaël Carré wrote :
> > Looks much simpler to me and avoid out-of-sync vlc for android and vlc
> > repo like you noticed a few days earlier.
> Probably right on this point, so far.
> But what happens when we have major core breakage on vlc.git, like when
> we have an audio core rework or an input/clock rework?
Of course, there are pros and cons to using master or a stable release/branch
as base for new work. On the one hand, you can test the new features and write
patches that can be merged upstream. On the other hand, you get bugs and code
churn. Live with it like everybody else.
For the sake of the discussion, lets imagine you target VLC 2.0 for your new
work, you finish it and you are exceptionally permitted to apply all patches
to vlc-2.0.git. Three months later VLC 2.1 is out. Now what? Well, you are
totally screwed because you did not target master. This is true for new ports,
but also for new plugins, and even more so for large reworks.
The good news is that Git is a powerful tool: rebasing patches has never been
easier. The bad news is that easier does not necessarily mean easy. So you can
stay on some mostly working version; nobody forces you to pull/rebase every
day. Then you can avoid most of the churn until you are happy, then rebase
once and update the code only once.
Also with Git, you can fork VLC 2.0 and live happy with a stable underlying
API and build system until the day when 2.1 freezes, 2.0 becomes unmaintained
and you get to throw all your nice work.
Personally, I do not care if Android uses VLC 2.0 or master as a base. But if
it targets 2.0, it will most certainly not be mergeable: Clean patches would
probably be too disruptive for a stable branch, and ugly patches would be,
well, too ugly.
More information about the vlc-devel