Re: [LAD] LV2 specification packaging

From: Brendan Jones <brendan.jones.it@email-addr-hidden>
Date: Thu Mar 22 2012 - 23:51:00 EET

On 03/22/2012 10:27 PM, David Robillard wrote:
> On Thu, 2012-03-22 at 14:48 -0400, Paul Davis wrote:
>> On Thu, Mar 22, 2012 at 2:42 PM, Albert Graef<Dr.Graef@email-addr-hidden-online.de> wrote:
>>
>>> To avoid any confusion about the packages in each release, you could just
>>> accompany each tarball with a manifest that lists the version information; I
>>> guess that this could be generated automatically from the version numbers in
>>> the corresponding manifest.ttl files. And you could maybe offer a little
>>> download page where this information is readily available in table form so
>>> that users and package maintainers can quickly find the version(s) that they
>>> want/need.
>>
>> or go the git route.
>>
>> sha-sum the whole thing. the result is the name of the release.
>
> A date is nicer, it sorts. A directory listing of such things would be
> a real nightmare.
>
> Note this tarball would just be a distribution for users to build, we
> actively don't want packages depending on lv2 everything with one
> version number at the source level.
>
> ... Well, heck, maybe we actually do. If it's all distributed in one
> tarball anyway, there's not much point in checking for every little
> piece you use.
>
> There is a certain elegant simplicity in depending on the state of "LV2"
> as of YYYY-MM-DD. I am very attached to the decentralized nature of
> LV2, but that doesn't mean the actual packaging has to be a shotgun
> blast.
>
> The way reality has worked out, stable extensions need to be curated at
> lv2plug.in or they tend to rot and confuse people. Perhaps the
> extension mechanism should only really be used during the development
> process, and we actively *do* want "LV2" to be a collection of
> peer-reviewed specs that work nicely together you can grab in one place
> and get on with your work.

If it is decided that this the course to take, would it not be better to
attribute a version number to the whole snapshot that meets normal
version numbering conventions rather than a date?

Downstream distros wanting to use a git snapshot can still do so by way
of there package release number. ie 2.x-0.1.git1A2B3CF

>
> In other words, perhaps a decentralized specification is a failed idea,
> and we don't actually want to encourage independent
> extension /publication/. You're still free to actually design and
> implement features with no centralized authority, but if you want it to
> actually be implemented by others, it should move in to LV2 proper when
> it's ready.
>
> It is with reluctance that I admit this, but that seems to be the
> conclusion of the experiment.
>
> -dr
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Mar 23 00:15:02 2012

This archive was generated by hypermail 2.1.8 : Fri Mar 23 2012 - 00:15:02 EET