James Carlson wrote:
> [Dropping Kerberos and SCM Migration, as they're really not involved
> in this; it's a tools issue at best.]
>
> Dan Mick writes:
>> James Carlson wrote:
>>> Only if you count printf("my version is %I%\n"); to be "good."
>> not printf, but %I% is perfectly sufficient for all the cases I've used it,
>> and there is no substitute. I'm still wondering why we strip all the
>> #ident strings, as that's even better.
>>
>> Many of the 'solutions' here don't lead immediately back to source files.
>> That's a real loss, however useless you think it is; it wasn't useless to
>> those of us who, well, used it.
>
> Thanks. You're talking to someone who has used these things himself
> many times.
>
> The problem is that this solution is lame. It's just stunningly bad.
I'm pretty sure everyone is agreeing that it's not perfect.
> A great many modules consist of multiple .c files
but a great many of them don't. And keeping #ident strings would solve that
issue for multi-file objects.
> *and* that the ID numbers mean nothing.
They mean exactly a source revision, if the one single rule of SCMS is
followed:
that you don't ever cut any sort of released version without a delta.
I'm pretty sure that's absolutely true of every release Sun has ever made, and
I
rely on it.
> Guess what happens if someone modifies one of
> those files without touching the one magic file with the version
> number in it?
1) thank you for offering me a guessing game (speaking of thanks), but I
understand that very well. #idents in all files would solve that today.
Something else that encodes filenames and versions would, too. And it's a
problem with the perfection of "one %I%", but it *doesn't make it useless".
It's just fine for all those single-file driver and other modules around.
> Or guess what happens when we need to map this back to
> a particular package or patch version?
Yes, it doesn't help a lot for that. I'm not interested in a patch version,
I'm
interested in a source version, because I want to diagnose the actual problem,
not diagnose RE. But no, it's about referring back to source, so it doesn't
really attempt to track the delivery vehicle, any more than the piston serial
number attempts to track the sale of the automobile. So?
> Or guess what happens when we have separate gates for separate releases?
Yes, one has to find the gate. It's easy in Sun's current structure, with very
little pain or management.
> Or when someone delivers an IDR built out of his own private workspace?
Well, that's what we call a "reassignable offense". There's a reason we have
RE, and gates, and gatekeepers, and release management, and it's about
accountability, and if you don't understand that, *clearly* you don't get to
deliver code to customers, ever.
> It's entertaining at
> best, and a total waste of time in the worst case.
I'm sorry, Jim, that's just wrong. It has absolutely answered the question for
me many times: 'just which version were you really running', quickly and easily.
No, it's *NOT PERFECT*. But it beats the hell out of *nothing*.
> I reject per-file versioning based on simple SCCS IDs as a viable
> answer for anything more complex than a "programming 101" class
> project, and it's probably not even good enough for that.
Well, as long as you're including "support of Solaris customers in the field by
an experienced willing engineer" in "programming 101", I can't really contest
that, but I sure disagree as to the utility of the imperfect solution.
> What I'd really like to see here is versioning that makes sense to all
> involved, so that administrators running "modinfo" (or its ilk) or
> using "myutility -V" (or some such) get information that actually
> means something about the version of the object, rather than something
> about the alignment of the stars at the moment the binary was built.
"alignment of the stars" is really unnecessary. Some want a binary stamp, some
want source references, and yes, we should be able to invent both....but after
all this time and all this discussion, no one has.
> This shouldn't be brain surgery. I'm not asking for something deeply
> complex -- just a set of usable version numbers that get applied to
> packages and traced to the binaries delivered by those packages
> through some _common_ mechanism; preferably something that is
> implemented in Makefile.master or thereabouts so that nobody has to
> code a single line to use it.
The perfect solution would certainly be nice.
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
