22 Mar
2012
22 Mar
'12
10:51 p.m.
On 03/22/2012 10:27 PM, David Robillard wrote:
On Thu, 2012-03-22 at 14:48 -0400, Paul Davis wrote:
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
On Thu, Mar 22, 2012 at 2:42 PM, Albert
Graef<Dr.Graef(a)t-online.de> wrote:
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. 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.
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev