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

[Alexander Fisher]

On 03/10/06, Isaac Richards <ijr at case.edu> 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 think, (rightly or wrongly), most people made the assumption that
all versions from the 0.20 branch would be compatible.  This would be
true whether the version was an official point release such as 0.20.1,
or taken straight from svn (0.20 fixes branch).

Under such a scheme, if the fix was critical and unavoidable, a 0.21
release would be required, (and a separate branch for this release
would be created before committing the fix).  Alternatively, perhaps a
workaround that didn't involve a protocol change was possible for the
fixes branch whilst the proper fix could have been made in svn trunk?

What's done is done, but perhaps a more strict versioning policy could
be followed in future releases?

Kind Regards,
Alex