Freezing protocol modules (was: Change list from 6.8 to HEAD, and 7.0 plans)

[Kevin E Martin]

On Sat, May 21, 2005 at 05:26:52PM -0400, Adam Jackson wrote:
> On Saturday 21 May 2005 17:01, Alan Coopersmith wrote:
> > Daniel Stone wrote:
> > > So, it's the 22nd of May.  People who want to do the libs should do so
> > > quick smart.  If people want to make any changes to protocol headers,
> > > you have until 0001 UTC on the 24th of May (that's about 103 hours from
> > > now) to either make your change, or raise a very convincing objection.
> > >
> > > If not, I'm going to post up tarballs of all the protcol modules and
> > > declare them final and that they shouldn't change for R7 unless someone
> > > has a really good reason to change it.
> > >
> > > Alan, does this sit well with you for 6.9?
> >
> > The only possible protocol change I know of that anyone's working on for
> > the 6.9/7.0 timeframe is the Xinerama standard vs. existing practice
> > compatibility issue I'm working on (though I haven't spent as much time on
> > it lately as I wanted to, so I don't know if it will be done in time).
> 
> I can actually think of a few things that may want changing in the protocol 
> headers themselves before release.  Xinerama BC and GLX updates primarily, 
> but istr an idea regarding Fixes being proposed a while back (maybe on IRC) 
> that might need an addition, if it gets implemented.

There is also the issue that was brought up in earlier discussions about
reworking the headers to separate the protocol parts from the library/
server-specific parts and only include the shared parts in the proto
module -- currently they are intertwined.  This will require a bit of
work.  It's on my TODO list and I've been trying out a few potential
solutions, but it's lower priority than other work right now.  As Keith
mentioned earlier, if we don't do this now, it's unlikely that we'll
ever get to it, so I'd like to see this included if possible.

> But those should all be backwards-compatible.  Right now I'm more worried 
> about the proto headers being basically usable, and they seem to be.  I'd 
> expect build-time fixes for them to continue to trickle in until basically 
> the RC stage, but that's fine.  Any structure additions to the headers 
> themselves should be treated like a bug that needs RM review.

The changes to separate the headers might cause some minor backward
compatibility issues, but only for apps that include the protocol header
instead of the library header by mistake.

Larger changes such as renaming files to be consistent would cause
obvious backward compatibility issues, and probably should not be done.

> I don't really see a reason to freeze the protocol headers _now_ though.  If 
> people want to start pre-packaging them and using them, great; presumably 
> they're doing so because the headers work on the system they care about, and 
> they'll be making sure that updates from now to release don't break that 
> system.

I don't think we should freeze portions of the tree yet.  We're still in
the development stage and there is much work to do, some of which might
require additional changes to the proto components.

Kevin