Stable/dev branches or should we provide pre-compiled binaries?

vsab · #1 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** · #2 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** · #3 05-06-2014, 01:46 PM

Quote:

Originally Posted by vsab

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** · #4 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** · #5 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 · #6 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 · #7 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 · #8 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 · #9 06-17-2014, 08:03 PM

i just wish you could compile on 32bit xp

**Uleat** · #10 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 · #11 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 · #12 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 · #13 06-18-2014, 09:41 AM

Very nice Vsab!!

**KLS** · #14 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 · #15 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.