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