Hello,
>> - I think a (git) version tag must only contains digits and dots in
>> order to be taken in account cleanly by eups.
> 	This is not the case.  Because we aren't doing version
> comparisons (other than equality) any more, version strings can be
> anything.  Just within the stack we have "+" characters as well as
> versions including ticket branch names and "g"+hash names.
Good. Then we can call it version 4.0.0rc3+qsClient2.

>> That’s why we may call the product xrootd-qserv (instead of xrootd, in
>> order to show that your version of xrootd is Qserv-specific, but this
>> will require DM agreement) and we must give to the xrootd product a
>> version number compliant with eups (like 1.0.0.0, 2.0.0.0, etc) …
> 	I don't think you have to do this.  I think you should
> name/version the package however AndyH would like, since it has an
> existence outside Qserv (unless this code fork is purely for Qserv and
> no one else).
AndyH has not made a named release. From his perspective, there is no 
stable point to tag (yet). But we need to assign some version identifier 
to say "Use xrootd X with qserv Y".  I'll make a wild guess and say that 
the API might stabilize in time for 4.4.0. Eventually (could be a few 
months, could be a year or so), the API will make it into xrootd for 
others to use.

AFAIK, the currently named version is "qs5", so can we have "qsc2"? Or 
"qs7"? (I already named something qsPatch6 in a failed experiment in 
rebasing, and we should not use it.)

>> - Could you provide a patch file that we could apply to the xrootd
>> version you rely on ? It would allow to use a classical xrootd version
>> and patch/build it with eups?
Do you want a patch from 4.0.0rc3? I can give you that. I don't know if 
the patch file would apply cleanly or work on any other xrootd release 
though.

>
>> Please note that creating a new package named xrootd-qserv won’t
>> impact, for now, the 2014_05 version. But if we don’t change the name
>> of the xrootd package and create a new version tag (2.0.0.0) in it, I
>> have to test that building 2014_05 will not use the last xrootd
>> (2.0.0.0) version but the one used during the distribution build
>> (master-gfc9bfb2059).
> 	This all depends on how your distribution stack is setup and
> tagged.  You can choose to have any set of versions (that is mutually
> compatible) in the distribution manifest.
Is the best documentation still the doc/eups.tex in mario's eups repo on 
github? It's all very confusing to me, but my interpretation is that 
each package version has its own manifest file and you can specify the 
dependent packages and versions there. Is that correct? Would you point 
me at a good example of a well packaged/setup/manifest-included set of 
files that I can poke at on a distribution server?

Thanks!
-Daniel

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1