Log in

View Full Version : Stable/dev branches or should we provide pre-compiled binaries?


vsab
05-06-2014, 11:57 AM
Currently to set up a server people have to download source that changes almost daily, and source in sql data that does also changes daily. At times this causes some disconnects, particularly with 3rd party tools.

Perhaps we could consider having a stable branch, and a dev branch on github? Active work on dev branch, then a reintegration for point releases (0.9., 0.10 or whatever).

Or a different way would be to supply precompiled binaries (at least for windows) so that people can install a known entity - which would help us support them better, and compile from source at your own peril/pleasure ;)

joligario
05-06-2014, 12:04 PM
The whole project is development-based. Just because the source updates (assisted by sql), doesn't mean you have to update. Pick a date, build it, then decide whether or not to implement changes in development as the project grows.

Akkadius
05-06-2014, 01:46 PM
Currently to set up a server people have to download source that changes almost daily, and source in sql data that does also changes daily. At times this causes some disconnects, particularly with 3rd party tools.

Perhaps we could consider having a stable branch, and a dev branch on github? Active work on dev branch, then a reintegration for point releases (0.9., 0.10 or whatever).

Or a different way would be to supply precompiled binaries (at least for windows) so that people can install a known entity - which would help us support them better, and compile from source at your own peril/pleasure ;)

I think this is a discussion that needs to be had. This is similar to keeping track of database versions to closer keep track of the schema for troubleshooting and code build purposes.

Precompiled binaries are not far off the chart. The new Wiki system allows for users to upload any files so hosting such things would be easy as pie.

This would also require that someone take ownership over declaring a particular build as stable keeping it at that version until someone is able to go through the series of testing necessary to declare the next build set stable without issues.

I have limited time to post on this but there are some things to start with.

joligario
05-06-2014, 02:42 PM
And I think that is just it. We had some people putting together "stable" builds. Then, the newest source change was adopted by almost everyone and the questions/complaints would rise: "Why won't this work?", "How do I get the latest source?", "I'm running 64 bit and the 32 bit won't work because my XXX is a different version.", etc.

Kayen
05-06-2014, 06:32 PM
Well in theory any source code changes to the main branch are suppose to be assumed stable by default (ie person implementing them tested it). Usually the only time the instability is caught is when it is distributed to a large audience who can more broadly test it.

vsab
05-07-2014, 05:25 AM
Read stable as "unchanging feature set" as opposed to "never crashes". This does of course mean an unchanging set of "known issues" too ;)

I appreciate your point Joligario, but the reality is that most people who compile and run servers have no programming nor even any basic SQL knowledge at all, so there are really 3 streams - players, server enthusiasts and developers (of course in reality that's a spectrum with some people being all 3).

Whilst I agree having a set of working precompiled binaries is no mean task in itself, I thought it might cut down on some of the support issues so devs can work on other things.

On the other hand it's a "development lite" task- it is more of a management issue than a development one, as is most dev ops/release management. That said, I'm not volunteering :P

ChaosSlayerZ
05-07-2014, 12:44 PM
we use to have dev build binaries....
it certainly was easier for newcomers to get a server running when they didn't need to figure out how to compile and whats the latest source and whats not.

sorvani
05-07-2014, 10:24 PM
We also did not used to have such a streamlined build process either. Building new now is very easy. No, it is not as easy as an installer, but creating a dev build will require them to still install all the pieces and do the database work. In our infrastructure, it simply cuts out the build process which is a very small part of the process now.

Astal
06-17-2014, 08:03 PM
i just wish you could compile on 32bit xp

Uleat
06-17-2014, 08:32 PM
A work-around was committed on 6/16/2014 (last night) at 9:17pm... Have you tried updating your local repo and re-compiling?

Scorpious2k
06-17-2014, 10:30 PM
I agree with Akkadius, I think we should offer it pre-compiled, maybe in packages with the appropriate DB... possibly other components too.

vsab
06-18-2014, 02:27 AM
I'm working on this, including a Windows installer (done, in fact) and apt-get style retrieval, installation and configuration of dependencies such as the correct version of Perl and MySql (not done yet). I'll probably only release x86 binaries at first though. You would need SP3 installed for XP, and Powershell 2 installed (both possible, tried it). It would almost work out of the box in 7 and 8.

Scorpious2k
06-18-2014, 09:41 AM
Very nice Vsab!!

KLS
06-18-2014, 08:25 PM
https://github.com/EQEmu/Server/releases/tag/v1.1.0

For now, I can't guarantee it will work but until we get something more perm setup.

vsab
06-19-2014, 03:57 AM
KLS - my system could well use these kinds of binaries. My plan is also to have maps and quests and database bundled, because in the past when I've upgraded a server and used older versions of those they don't work properly.

I updated the maps from SVN but I suspect these are using the old map system not your new one, or won't it matter for now?

My aim is to have the simplest install ever for someone who has discovered this site and wants to get a working server running with the smallest amount of hassle.

The user would write this in a command prompt:-

> cinst EQEmu

But the installer I'm writing would:-

1. Download and install ActivePerl-5.16.3-x86, if needed
2. Download and install MariaDb, if needed
3. Download and install Visual C++ Redistributable Packages for Visual Studio 2013, if needed
4. Download and install a precompiled EQ Emu binary set. I could actually use yours and just unzip it but I already have an installer, which sets up the folder structure
5. Install maps and quests in the correct location, plugins in the correct locations
6. Set up Maria DB correctly with a default password (probably "password" :P )
7. Install the PEQ database

If I get that working I might make another package to install Apache, the PEQ PHP editor and HeidiSQL. Or maybe a package to install the plugins/mods that Akka has published.

KLS
06-19-2014, 11:57 PM
Newer maps are significantly smaller, also you could have it generate new maps from an eq install then copy them over (takes about 5 minutes for me).

Scorpious2k
06-21-2014, 11:27 AM
My aim is to have the simplest install ever for someone who has discovered this site and wants to get a working server running with the smallest amount of hassle.

I really like this idea.

But the installer I'm writing would:-

1. Download and install ActivePerl-5.16.3-x86, if needed
2. Download and install MariaDb, if needed

WOW! I thought I was the only one using MariaDB - well, me and Google now that they switched. :P

3. Download and install Visual C++ Redistributable Packages for Visual Studio 2013, if needed
4. Download and install a precompiled EQ Emu binary set. I could actually use yours and just unzip it but I already have an installer, which sets up the folder structure
5. Install maps and quests in the correct location, plugins in the correct locations
6. Set up Maria DB correctly with a default password (probably "password" :P )

The default always seems to be (in guides) DB name eqemu and password eqemu. If you wanted to get clever you could grab the computer name (system variable COMPUTERNAME) or the current user name (system variable USERNAME) as a password making it unique to each installation, easy for the user to remember, and still a pretty crappy password otherwise.

7. Install the PEQ database

You could also supply them with a startup batch file too. If you do, be aware there is a program called timeout.exe that is FAR better than using ping for delays and it is included with windows.

If I get that working I might make another package to install Apache, the PEQ PHP editor and HeidiSQL. Or maybe a package to install the plugins/mods that Akka has published.

Great!

joligario
06-22-2014, 10:25 AM
Temporary stop-gap posted until you come up with final solution.

https://github.com/EQEmu/Server/wiki/EQEmu-Binaries

vsab
06-23-2014, 04:04 AM
Been a bit busy, there is a bug in one of the dependencies (MariaDb in fact)- so I may have to make my own installer, but I'm up to step 5 pretty much. One night this week I will get the rest sorted.

It will never handle an upgrade situation (too many things can change), and I need to do some checks in regards to how it installs on a non clean machine (using pristine VM's for testing).

I was going to supply two configs and two startup files - using the public login server and using a local one.

I'll think about changing the password, I was probably going to just insert the computer name as the server name in the config. Generally speaking, the fewer variables between each install the better in terms of us supporting it.

vsab
08-28-2014, 03:49 AM
Note on progress:- none. This is because of RL issues for me, but even if I did work on it the codebase is in such a transitional state it would be hard to get a stable snapshot, however I was at about 90% of the way when I stopped.