Attention Custom Coders & WoW Server Admins - Suggestions for sanity sake.

As you may be aware, Trinity Core is an ongoing project always evolving and changing most times for the better. Unfortunately these same changes make it hard for Custom Mod Developers to stay on top of the changes to ensure that patches will work as intended, this is also a headache for you WoW Server Admins as this usually equates to having to go without favorite mod hasn’t been updated to build cleanly to minor change X or Y in the repository.

To minimize the issues related with this, I’d strongly encourage both coders and server admins to only use Trinity Core revisions that are paired up with TDB releases. Consider them as stable releases, this will allow the coders to take advantage of a core that isn’t constantly changing, and for server admins it means the mods will work for months at a time between TDB releases. The current TDB revision is da9865b6833f94b7fd.

If you’d like to go this route use the following to revert back to that revision:

git reset --hard da9865b6833f94b7fd

Then rebuild the core.

Now I don’t represent the Trinity Core project, nor am I developer for them so take this as suggestions but if we can follow these practices it’ll make life easier for all of us at least until there is major change to the project. Let me know what you guys think.

Why with TDB?

Maybe with stable tag https://github.com/TrinityCore/TrinityCore/tree/stable ?

The current documentation has users use TDB and optionally use the SQL updates from the current revision. Additionally the documentation doesn’t specify the user to use the stable tree, or mention it at all which defeats the purpose of having the stable tree altogether.

As TDB are generated quarterly and the repository is updated to reflect this(as the SQL updated folder is condensed into the TDB then cleared) , it’s the best way to confirm that there having been any database or Core changes where both wouldn’t be compatible with each other.

There are a few problems with this advice:

[ol][li]When you come looking for support the first thing you’re told to do is update your core anyway[/li]
[li]People will post bug reports for an old core that may already have been fixed (people don’t search)[/li]
[li]You miss out on quest fixes and other nice tidbits[/li]
[li]If the mod dev. stops maintaing it, waiting for a new core / db pair won’t matter, the mod still wouldn’t work[/li]
[li]We need people to update from time to time so bugs get found and reported[/li]
[/ol]
Granted there’s no need to update every day but staying on an old build for months isn’t really doing the project any good and you just make it harder for yourselves when you come looking for support (see #1 above).

mrsmite, I partially agree, but, if TC devs would set things up properly, then the supported rev would be the stable rev, or TDB rev, or whatever, and when a user opens an issue, a dev branch would be opened, as mangos says they are doing, or, a fix gets dropped in the existing dev branch, testers report on whether the fix is working or not, when working, and complete, it would be merged, or cherry picked into the “stable” and normal users would be prompted to update only when the stable is updated, and not every time the devs push a commit, compilable or not… This is why I push so hard for these changes to be made, it would, ultimately, make everyone’s lives easier. Think about it, would you rather support a rev considered stable, or every single dev commit?

I actually setup this thread to bring the discussion point up, I honestly dont think something updated quarterly should be used as the only form of updating. It’s just odd that a project of this age to completely lack some sort of release cycle along with testing. How many commits have been merged that we quickly have to commit a fix to allow it to compile? I’m all for up to date code and database entries, but do we want users always using untested bleeding edge code all the time?

I’m sure Mod Devs are tired of potentially having to update their code on any single dev commit that could break their own. Major/Minor releases I’d be okay with that, once a week checking to see if my code works, if so great otherwise go into maintenance mode.

@Paradox

My point was that none of it matters if the person who wrote the patch / mod is not updating it. Even if the Trinity repo functioned as you said, when the next “stable” release was posted, the mod still would be broken. In that case the people have stagnated for no reason.

Plus if everyone stayed on old code, who would find the bugs? After all the stuff that’s pushed to the repo isn’t bug tested first /emoticons/default_tongue.png

The thing is the mod devs don’t have to update their code for every commit. They just need to be responsible enough to let their userbase know that the mod only gets updated every X weeks or months.

Unfortunately the mod devs don’t usually extend that courtesy to their userbase. Instead they get pissed from people asking for updates and just abandon their mod completely.

@Paradox

+1

A bit sad that Trinity is done for the developers themselves and not for those who use it.

I understand that I have no right to demand, but would like to see us (the users) have at least heard.

Users who know jack shit about programming and staying on an older commit will complain about it not working and needing update no matter what the custom code dev tells them, most of them don’t even bother to read anything the dev says, period, so, getting them to stay on a rev that is not the absolutely most current is a pipe dream, unless they are forced to by the untested dev work not being in the main repo/branch that the public uses. and stop all this crap about “who will test it?” the people who want to test it will test it, and those too ignorant of the process to even edit their conf file correctly will stay on the main repo and not have to complain about a whole lot.

Since I’m new I haven’t experienced the issues with Modders of the past but the active mods I’ve seen maintained and posted in the forums only seem to respond to when the mod actually breaks instead of X or Y time periods because staying on top of commits is insane but equally so is ignoring users who are just following the current SOP (ie.: git pull, patch, then build often).

My desire to update Trinity fluctuates wildly. In the summer months I play the client less so I update less. I also get sick of playing the client at times and just need a break from the grind so I may not update trinity for a month or two. When I’m actively into playing the client and not busy with other things I tend to update much more often and waiting for full database releases rarely works for me since those can be a month or even over two months old at times. I’ll often wait for patches to be updated before I’ll update my core.

I sympathize with people trying to maintain patches. I’d rather see patch maintainers who don’t want to update frequently post the revision and date the patch works and a notice that the patch won’t be updated until another specified date. I’m sure it’s frustrating when someone updates a patch one day and a day or two later someone is complaining it won’t apply or practically demanding it be updated.

Ultimately I’d rather see some of the most popular patches cleaned up and permanently added to the core.

I am with Zaranthos. I have followed Trinity for some time now and only update my 1 person (me) server from time to time. Usually, every month or 2. I also agree with Paradox. There must be some middle ground here where some of the major custom code we all use all the time is easier to maintain/patch OR added to the core so there is no need to keep patching separately. I have read post after post requesting that the Auctionhouse Bot be added to the core. That is one of the major patches I believe would be beneficial.

Cvmagic, I think these are the kind of threads are beneficial to the Trinity community. They at the very least, get everyone talking about how to streamline things. I am sure Paradox is tired of seeing the “I can’t do this…” or “I can’t do that…” threads… /emoticons/default_smile.png