Release FB7

[wyld-sw]

Long time coming, for sure. I'm got a few tasks that I need to complete before this can happen:

• compile release notes from fb7a1-current into a "brief' overview.
• introduce starterdb, a version of advancedb that is upgraded for FB7 and removes a few things that were inactive or broken. basedb and advancedb would then be retired. (#574)
• ~default the registration sysparm to no~.

Please let me know if any of the above needs clarification or correction.

@tanabi Do you see anything that we must solve before the next release?

@foxbird Are there any things you'd like to see from a Windows standpoint before releasing FB 7? Documentation, addressing compiler warnings, etc.? The repurposed #576 has a useful link.

@digitalcircuit Would you recommend any changes to the current CI setups?

Does anyone have any suggestions about announcing the release beyond putting the files up on GitHub and fuzzball.org?

[tanabi]

Hi guys;

If nobody else is willing / able to update the windows documentation, I can give it a shot. In particular I'd really like to see a README come through on the appveyer build that has the instructions around the VC Redist.

I disagree with default registration sysparm to no :) I believe that's inviting a security hole that newbies will not understand. I'm not sure why you want to do it that way; I think we tried to talk about this earlier but one or both of us was idle at the time. Synchronous communications suck sometimes.

I think that's the only issue (other than the ones listed by Wyld) that I have.

[wyld-sw]

My mistake. I don't know what I was thinking, but yes - allowing folks to "create" out of the gate is a Bad Idea. I may have got it confused with just changing register_mesg based on the results of a "game setup" tool. I definitely got muddled there. Anyway, that's definitely not part of the list - sorry for the confusion.

[tanabi]

No worries! Yeah, register_mesg needs to not refer to Tygriss MUCK at least -- as many references to specific MUCKs we can remove as possible, I think, is a good thing especially since so many of them no longer exist :/ But I'm gald we're on the same page with registration! :D

[digitalcircuit]

@wyld-sw For now, all that comes to mind is including a suitable README.txt in the Windows build artifacts as @tanabi suggests. I'll work on that tonight (EDT).

Last I recall, switching to a 64-bit build would require finding a 64-bit version of pcre.lib - perhaps that's feasible by now? A lot has changed since my attempt in 2016 - that said, I feel like incrementing Visual Studio compiler versions and swapping out pcre.lib should not be done right before a release :)

And to be clear, I'm not at all opposed to others changing things with the CI setup. Windows builds and CI in general are an area I'm still learning.

[foxbird]

I'm figuring that the windows readme can be as simple as:

1. Unzip to a folder of your choosing that has no spaces in it.
2. Install the x86 VC redist for visual studio 2019 (yes, even if you are running 64 bit windows) [use link I provided before]
3. Install your database and support files into the data directory.
4. Run fbmuck as you normally would (see linux documentation) to start the server.
5. Optionally, use the restart -c command to create a restart.ini file, which you can edit to help restart the server after shutdown.

There are all kinds of additional topics you could put in there. Like, how to install things as a windows service, or troubleshooting, or logs.. maybe even documentation about the console options (to show/hide/deallocate the console).

For a future release, if you want me to look into hooking into the windows service registration stuff, I can see if that's accessible and put it in restart (since fbmuck wouldn't be a good candidate as it doesn't handle its own swapping of database files). And, I can probably put together both a comiling.md and a running.md file in the win32 directories. I might have time to fiddle with that tomorrow, but 'sometime in the next week' is more realistic.

As for 64bit versions, I think I built the original pcre.lib from source. I can probably do so again and get a 32 and 64 bit version. However, switching to 64 bit will also bring out a TON of compiler warnings. size_t becomes 64 bit I think, and size_t and unsigned int (or similar flavors) are used interchangeably with that. And they aren't the same. So it's a lot of loss of data warning stuff. Enabling 64-bit compiling on windows is as easy as switching your tool command prompt. I can produce a list of warnings if you'd like to take a look, or just submit a PR to address them. But it might touch all kinds of stuff. Best for a future release.

If any of you have a latest pcre source code you can point me at, I'll see about compiling that latest one.

[digitalcircuit]

@foxbird Would you prefer I wait for you to put together a proper compiling/running set of documents, or do you think it's still useful to have a simple README text file that can be replaced/removed in a later pull request as needed?

And, pardon, I didn't mean to step on any toes. I wasn't sure of the timeline here, and I probably overreacted.

[foxbird]

No toe stepping has occurred! I don't know what date we're trying to hit. And honestly, the README_WINDOWS.md file is probably plenty. Maybe just move the "quick start" section to the top instead of the bottom, and it's probably all good. Then you can just change the appveyor build to also pull that README_WINDOWS.md into the build/game directory where it creates its artifacts. That readme is already pretty much perfect, so I'm not sure why you'd need another.

[digitalcircuit]

Phew, I'm glad to hear that. And thank you! In the open AppVeyor Windows CI pull request, I've moved the "Quick start" section up, and added a step to render the Markdown to HTML too (.md.htm), not just plain text with Windows line endings (.md.txt).

We definitely can still update the actual documentation in the Markdown files, too - it could probably be simplified, and I'm not sure about spaces, etc. The pull request was more just getting it automatically included into the build artifacts.

[wyld-sw]

Thanks guys! There’s not a hard date we’re trying to hit; it’s just a sense of needing both a non-beta release and a roadmap before too long.

[tanabi]

@wyld-sw I think this is done right? Time to close this one. I'm starting to look at 7.1 issues to start in on myself.