22 Mar
2012
22 Mar
'12
11:15 p.m.
I like the idea of an overall version number, so, LV2 V2.1 is released
which contains foo v0.7, ba v1.1, thing v0.4.
Over time foo is updated to v0.8, LV2 V2.2 gets released.
Any client/host using LV2 can then claim a version compatibility, ie
V2.1, but not V2.2.
Seems the most understandable approach to me, in my layman's terms.
Cheers
Chris
On 22/03/12 21:56, David Robillard wrote:
On Thu, 2012-03-22 at 22:51 +0100, Brendan Jones
wrote:
Well, I don't know about
that. Each interface is still a completely
separate thing, and the version numbers for them are maintained
accordingly.
It seems important that a version bump in, say, the state extension,
doesn't mean anything in the core has changed. Paticularly for
developers that don't use state. However, perhaps this argument is
invalid since LV2 specifications never break (their URI must change if
they do, there is no major version).
That's a pretty dramatic change, but it is simpler... a lot simpler...
having all the NEWS files and everything merged, I don't know ...
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On 03/22/2012 10:27 PM, David Robillard wrote:
[...]
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?