[vlc-devel] [vlc-commits] commit: contrib: Fixed SVN version number for contribs. (Pierre d' Herbemont )

[Pierre d'Herbemont]

On Thu, Nov 18, 2010 at 12:25 AM, Jean-Baptiste Kempf <jb at videolan.org>wrote:

> On Wed, Nov 17, 2010 at 06:55:31PM +0100, git at videolan.org wrote :
> > vlc | branch: master | Pierre d'Herbemont <pdherbemont at free.fr> | Wed
> Nov 17 17:36:34 2010 +0100| [50c315b8e37a6193792dc1a9cca22583a05d6284] |
> committer: Pierre d'Herbemont
> >
> > contrib: Fixed SVN version number for contribs.
> >
> > We want to be able to re-create the exact same build for a given vlc
> version, including contrib.
>
> No.
>

Let me rephrase that for you "I want" and then, "you don't". :)


> We do that for the stable version, not for the development version.
> See 1.0 and 1.1 branch.
>

It's certainly a good start. And as the release manager it's up to you. But
fixing now and then external dependencies, even during development cycles is
a waste of time.

On Mac OS X, the simplest work around I have found is to use by default
pre-built binaries, since it also reduce the build time. This also ensure
that we have a very precise git-revision->set of contrib link. I would
strongly advise Windows folks to do the same.

Now the reason I do that, is that, what if we want to re-create the very
same contrib snapshot from a given revision number? We can't. It's a pity
not to be sure that the regression is not in the contrib from two snapshots.

What also about GPL there? Since we are redistributing nighlties, we have to
re-distribute the exact sources, and at least point at what version we've
embed in.

No, seriously, I think this has to be done. What concern do you have? If the
idea is to be able to simply update to latest SVN revision, we could do a
script for that. Is that it?

Pierre.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20101118/4e8277ab/attachment.html>