[rfk-dev] bugs -- pedro overthinks version numbers!

[Eric S. Raymond]

Peter A. H. Peterson <pedro at tastytronic.net>:
> If it's too embarassing to imagine me overthinking these things as a
> robotfindskitten fanboy, you can instead think of me as a zealous
> advocate for the defense of rfk tradition. It's my fiduciary duty to
> make the best case I can, while deferring to the wisdom of the group.

Understood.  robotfindskitten is performance art; it is very important
that we preserve the peculiar esthetic of the original.  You are not
"overthinking", you are defending the integrity of the work.  I get
this and do not need persuasion about either its desirability or
your ability and authority to do it.

> So... about the version string:
> 
> On the one hand, my desire to keep the X.YYYYYYY.ZZZ version number is
> simply out of tradition. But of course it's obvious that not everyone
> would appreciate every little idiosyncrasy as a feature worth keeping
> for, as Eric said, "hysterical raisins."
> 
> But there are non-hysterical raisins for which I like the traditional
> version string.  I've always seen it as a satire on version numbers in
> general. But more than that, it's a little mysterious and odd that
> there are so many numbers in the version. It raises questions like
> "what do they mean?  why are there so many? What is their
> significance?"

I agree, and value the odd version string for exactly these reasons
myself.

> Of course, there's ultimately no more significance than what your
> fingers happened to twiddle when you made up the least significant
> digits of the minor number. BUT the NKI count -- which seems like it
> is simply taking the version string satire to the extreme -- actually
> *has* meaning, but a meaning that is basically meaningless within the
> game itself (since you only encounter a handful of NKI at a time).
> 
> So, I like the traditional version string in the same way I like the
> fact that SSNs and driver's license numbers are both simulaneously
> meaningful iff you know the code AND an exercise in the absurdity of
> giving everything a number. And I think that this
> uncertainty/absurdity (along with many other elements, like robot's
> back story, etc.) lend an air of mystery and scope to the simulation
> that sets a person's mind into this strangely bemused state of
> wonderment that is pretty much my favorite thing about the game.
> 
> A much shorter way of putting this is that a short version number,
> e.g., 1.234 is just like the version number for a million other pieces
> of software and doesn't create any kind of response in the player; if
> anything it creates a yawn. I might rather have no version number in
> the status bar than a 1.234 version number.

Agreed on all counts.

> THAT SAID, regarding the NKI count...
> 
> It also occurs to me (thanks to Eric's comments) that in the old days,
> the NKI count actually *WAS* a meaningful part of the compiled version
> number, since NKIs were compiled in but were functionally independent
> from the code. It may have been partly a joke, but it also made sense
> in a way that is no longer true with external NKI. Putting something in
> the version string that isn't "a reflection of the revision level of
> the software as compiled" does seem like something of an abuse of the
> notion of version strings. Maybe that is confusing and mysterious in a
> dissonant way. 
> 
> So maybe it's time to retire it. I could go either way.
> 
> I guess an alternative would be to display the number of currently
> availble NKI, but not as part of the version string per se. It could
> be something like x.yyyyyy:zzz or x.yyyyyy (zzz). Or maybe
> X.YYYYYY nZZZZ. But maybe that's just not an improvement.
> 
> Thoughts?

I think we should keep the present version-number format.

I think the minor part should be a count of NKIs in the file or
files we ship with the distribution. I do not think it should
change at runtime if the user installs new NKI files.

This would accomplishe the traditional purpose of the NKI part, which
is to be a minor version number tied to the release level of the
tarball.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>