Re: Stable branch releases?

[Avi Kivity <avi@redhat.com>]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Glauber Costa wrote:
>>>
>>> As we're getting close to kvm-xxx anyway, maybe we could forget this 
>>> number
>>> scheme, and adopt something that tracks linux. This way, you know 
>>> exactly what
>>> kernel a released is based on. Something in the lines of kvm-29.1  
>>> for updates
>>> to the .29 series, (of course _this_ scheme is bad, because it 
>>> brings clashes)
>>>   
>>
>> It also ignores qemu, which is larger contributor to user visible 
>> features...
>>
>> Maybe stable releases should have separate packages for kvm and qemu: 
>> kvm-modules-2.6.29.1 and qemu-kvm-0.9.1.17.  Users would pick the 
>> latest of each, and would only need to upgrade a component that's 
>> changed.
>
> Yes, this would be IMHO the best overall solution.  Can we take 
> kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1?  Most users 
> don't need newer kernel modules if they have a relatively recent distro.
>

There's a slight snag here.  The kernel module wants bits from the 
userspace package (the backward compatibility kit and makefiles); the 
userspace package wants some kernel bits (header files).

I think we can work around it by using 'git symbolic-ref'.  kvm.git 
would have a maint/2.6.29 branch, which would have an alias called 
maint/0.9.1.  Similarly, kvm-userspace.git would have a branch called 
maint/0.9.1, with an alias called maint/2.6.29.  Commits into one would 
automatically appear on the other.

This sound reasonable?

-- 
error compiling committee.c: too many arguments to function