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

[Isaac Richards]

On Tuesday 03 October 2006 5:57 pm, 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.

There hasn't been a release with a changed protocol version.

> 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.

Look at how fast they go in normally.  Commits have generally been slower for 
the past month than they usually are.

> I would say your release was at least a month premature. I am not
> knocking your product, its great in most regards but the
> alpha-beta-release portion of the testing cycle seems to be missing.
> Perhaps this is due to the program being a non-commercial group effort.
> I have not coded for a group effort before and this release style may be
> part of that mentality. To me, its just poor style to have two different
> incompatible software versions both using the revision 0.20

Let's repeat.  There hasn't been a release with a changed protocol version.  
Am I supposed to make a new public release every time something incompatible 
changes in SVN?

Isaac