Modules created and initial files checked in

Daniel Stone daniel at fooishbar.org
Mon May 9 12:42:15 PDT 2005


On Mon, May 09, 2005 at 12:19:55PM -0400, Kevin E Martin wrote:
> On Sun, May 08, 2005 at 06:10:23PM +1000, Daniel Stone wrote:
> > Haven't really had time to look at all this before now, but I spent some
> > time on it on the weekend.
> > 
> > Firstly, how are we going to version the individual components?  I think
> > that we should continue as we've been doing, with, e.g. version 2.2.1
> > for libXv, 2.2 for the Xv proto, et al.  The alternative, of course,
> > being 6.9.99.1 (e.g.) for all the modules, but then you start bumping
> > the version number even where there haven't been any changes.
> 
> That's a really good question.  When I created the initial proto module
> components, I just used 7.0 for the version numbers to get the ball
> rolling, but I think you're correct that it would be better to use the
> library versions as a starting point for the corresponding proto
> packages.  Note that as we move forward, the protocol and library
> version numbers will probably get out of sync since we can make major or
> minor changes to a library without a corresponding change to the
> protocol headers (e.g., deprecating library functions or adding new
> functions that make use of the existing protocol).

Sure; currently the Render extension is at version 0.9, while the
Xrender library is at 0.9.0.  I think it was 0.8/0.8.3 for the last
major protocol version.  I think we can work fairly well within this
model (x.y for protocol, x.y.z for library).

> This re-raises the issue that I raised in an earlier thread regarding
> library headers being intertwined with protocol headers.  Ideally the
> protocol and library interface headers would be separable, but right now
> they are not.  Making all headers separable (and moving the lib headers
> to the lib module) could cause problems for ISVs who include the proto
> header instead of the lib header.  I would like to see this fixed, but I
> don't know if this is the appropriate time.  What do others think?

I think we should just try to fix as much as we have time to; as long as
we have clearly declared intentions, inconsistency isn't the worst thing
ever.  It's not like we're not massively inconsistent throughout the
entire tree already, anyway.

> > One comment: can we *please* not call the MIT-SCREEN-SAVER protocol
> > module, 'SS'?
> 
> Sure.  What would you suggest as an alternative, ScrnSaver?

Preferably, yeah.

> > Other than that, looks good, and I was banging at the server two weeks
> > ago and yesterday, and I've got a cleaned-up server core that links now.
> > Will post the symlink.sh modifications when I get time.
> 
> Excellent.
> 
> Kevin
> _______________________________________________
> xorg-modular mailing list
> xorg-modular at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-modular
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.x.org/archives/xorg-modular/attachments/20050510/5af70c14/attachment.pgp


More information about the xorg-modular mailing list