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

[Peter A. H. Peterson]

Quoting Eric S. Raymond:
> Peter A. H. Peterson <pedro at tastytronic.net>:
> > What do people think about having a release version number -- the
> > X.YYYY number -- which is relevant for releases, packages, etc., but
> > at runtime the version number in the status area displays a dynamic
> > count of the NKIs loaded at startup?
> > 
> > That way, the version number from the perspective of the build tools
> > is separate from the more whimsical tertiary NKI count.
> 
> I'd be opposed to this change.
> 
> If part of the version number is going to be computed at runtime
> rather than being a reflection of the revision level of the software
> as compiled, I don't see any point in concatenating it to the version
> number other than confusing people.

Before I respond to this, I think one thing that makes the
robotfindskitten development process unique is that it is a
simple program that has been stable for so long that every minute
change is noticeable and potentially significant within the extremely
limited context of robotfindskitten. Insignificant in the real world,
but significant in the robotfindskitten world. Which somehow seems
entirely appropriate.

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.

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?"

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.

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 don't have a particular opinion about [build tools], although I
> > side towards inertia/tradition/whatever will be easier for
> > downstream packagers/current maintainers, etc.
> 
> And it's not one I have a strong position on.  I have come to
> generally dislike autotools and would enjoy scraping those barnacles
> off our hull, but it's not something that I judge *needs* to happen.
> The suckage can be lived with.

I get that. So, does anyone else have an opinion on this matter?

> I hope my NKIs meet with your approval.  The only one I'm really wedded
> to is the RFC1149 joke - I'd be sad if you nixed that.

Totally. As far as I can tell they are all fine, and I think that more
NKI are certainly welcome from you or anyone else. If necessary, we
can come up with some kind of group editorial process, or set up an
nki-editors list or something. But that won't be necessary if
historical NKI submission rates are any indication.

pedro

-- 
Peter A. H. Peterson
Graduate Student Researcher
Laboratory for Advanced Systems Research
University of California, Los Angeles