[mythtv-users] protocol version mismatch, what's the best solution?

[Kevin Kuphal]

William Munson wrote:
> Isaac Richards wrote:
>   
>> On Tuesday 03 October 2006 2:23 pm, William Munson wrote:
>>   
>>     
>>> Kelly Reed Schuerman wrote:
>>>     
>>>       
>>>> I started out with myth 4 years ago compiling everything but have
>>>> since moved to binary packages, but this upgrade has brought me back
>>>> to compiling which I haven't done for some time so I have some
>>>> questions.
>>>>
>>>> I am having the protocol version mismatch issue with FC5 atrpms binary
>>>> backend (protocol 31) and Ubuntu Dapper source build frontend
>>>> (protocol 30). I built from source on the frontend in hopes that it
>>>> would use protocol 31.
>>>>
>>>> What is the best solution?
>>>>
>>>> Build the FC5 backend from source to back it off to protocol 30? Will
>>>> there be any database version issues with this method? Is it possible
>>>> to load an older binary build for FC5 to back it off to protocol 30,
>>>> if so how do you specify that build with yum? Also, any database
>>>> issues?
>>>>
>>>> Are there any binary packages for Ubuntu for protocol 31? Is there a
>>>> source package somewhere that will compile to protocol 31?
>>>>       
>>>>         
>>> You will need to build the 0.20-fixes branch to get a compatible proto
>>> 31 frontend. The poor choice to change protocols without changing the
>>> release rev is causing many problems for those who install packages.
>>>     
>>>       
>> How exactly do you propose to deal with different package maintainers 
>> packaging different bits of (unreleased, pulled from svn) code?  If I were 
>> put out 0.20.1 right now from the fixes branch, that won't change the 
>> situation at all.
>>
>> Isaac
>>
>>   
>>     
> I would have released 0.21 when the proto changed. That would fix the 
> situation. Actually I would have held off releasing anything until more 
> testing was done. Looking at how fast the commits are flying out of SVN 
> I would say your release was at least a month premature. I am not 
>   
You seem to miss that some commits are for new development purposefully 
held off until after the 0.20 release.  And also, if more people were to 
be involved in testing prior to the release (there was a two week or one 
month feature freeze before the release) then more of these fixes would 
be found earlier.  Since there also hasn't been an official release 
since 0.20, any protocol change is only in the development versions 
which people should be well aware of before running them.  And yes, even 
0.20-fixes is development because it is, in reality, a pre-release of 
0.20.1.

Kevin