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:
>> 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?
> 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@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:03 2012
This archive was generated by hypermail 2.1.8 : Fri Mar 23 2012 - 00:15:03 EET