why gzdoom features are not belong to zdoom

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

Locked
User avatar
Heather
Posts: 1
Joined: Thu Apr 28, 2016 14:38

why gzdoom features are not belong to zdoom

Post by Heather »

why don't you just pull request those features to zdoom? how to check on what zdoom version current version of gzdoom is based?
User avatar
Rachael
Developer
Developer
Posts: 3646
Joined: Sat May 13, 2006 10:30

Re: why gzdoom features are not belong to zdoom

Post by Rachael »

This post is a bit unusual but I will do the best I can to answer it...
Heather wrote:why don't you just pull request those features to zdoom?
That would defeat the purpose of forking. In that case why not just pull request all of Zandronum's features to ZDoom, too? That would probably cause more harm than good - too many different coders, too many different coding ideas, the devs *DO* work together as it is (it may not seem like it but they do) and Graf is one of ZDoom's main coders as far as bug fixes and maintenance is concerned but has also developed a few new features of his own. Without Graf, we would not have DECORATE at all in ZDoom.
Heather wrote:how to check on what zdoom version current version of gzdoom is based?
You can't, really, but just know that as far as releases go, if GZDoom releases at the same time as ZDoom, then that version of GZDoom is based off the recently released version of ZDoom.

If GZDoom releases independently of ZDoom then that version of GZDoom is based on an in-development version of ZDoom.

When looking at development builds, the only real way to tell is to check when the last "rheit/master" merge occurred. Those merges usually bring in ZDoom's latest commits up to that point.
Locked

Return to “GZDoom”