MOSS Open Source Shard Test

[JWPlatt]

I'm currently on a'moaca's completely open source MOSS test shard listening to music in Minkata.

It's a beautiful, exciting thing.

[Mac_Fife]

Oooh, I've got to try that, but I can't leave the office until 3:30

I think this is a fantastic achievement, and is way beyond any expectations I had back in December when Chogon asked me "Have you spoken to JW recently?" Of course, MOSS was beyond my horizon at that point.

[Mac_Fife]

Having installed this last night, there were a couple of "gotchas" that I discussed with a'moaca':

• PhysX System Software revision - original Cyan delivered PhysX installer is out-of-date for this build
• DirectX 9.0c "versions" - some older "redistribution" versions may not include all the required DLLs

The first is noted in cjkelly1's build instructions, but the second isn't. These probably warrant going into a seperate "Installation note" of some sort. I'm not too sure how best to handle this because it'll be a kind of dynamic thing as people change builds etc., maybe using different SDKs and libraries. Maybe better as a set of trouble shooting notes.

Thinking about how to tie these observations to a build also spawned another thought: Should we be starting to track/manage a new set of build IDs? It could get really confusing for bug tracking if we there are six builds all numbered "1.897"

[a'moaca']

The problem is that we really need either the 1 or the 897 or both to become a protocol version. I'm not choosy which, but if a time comes when the client and server can be somewhat independent (that is, the client does NOT check itself against the server's hashes), protocol negotiation will really become important.

I think Cyan meant the 1 to be sort of the protocol version, since they call it a "branch ID". Unfortunately, the 897 is functionally the protocol version; I use that number in the Wireshark plugin to figure out which protocol is being used (it changed at least 3 times during MOUL).

I think for your purpose ideally it would work like svn builds of things like Wireshark, where the version string is generated from the checked out version info. That's what the 897 is, incidentally, obviously a svn version. If we had, I dunno, a URL+revision version string, maybe? I was not going to worry overly much about it myself, though, until someone wants a protocol change.

- a'moaca'

[Mac_Fife]

I guess I'm just looking for a way that a user can definitively describe which version of a product they are using. It could be something written in the client's Release Notes for that matter, but that "1.897" version number is something that everyone sees upfront, so it seems the most obvious thing to adjust. I'll defer to a'moaca's more knowledgable judgement on protocol version, that suggests that the "1." probably ought to be retained.

On the "gotchas" I mentioned, I'm thinking that I should mabe start a series of "Technical Notes" wiki pages: Create one for every workaround or fix that someone might need to apply (things that are outside of bugs that would be tracked in JIRA) then we can point to them from an index page. That way if the issues/fixes are different for different builds, each can be documented separately.