Committee Meeting Notes: 10/2/2012

#1 I have some comments regarding some of the new business bullet points.

• Versioning:
"The major.minor format makes less sense in this format with more frequent updates to the master branch."
I disagree, jumping on board the whole single digit version number scheme would be very bad idea and it'll just look like a race to the highest number yet again as seen from the likes of Chrome and Firefox web browsers. If you really don't want to manage versions then simply change it to a release date stamp instead: 2012.10.03 (today) for example. Else, just resume on from v1.2 and keep moving forward to 1.2.x++ or 1.3.x, etc... see Ogre 3D's roadmap as the proper way to do version releases and plan ahead.



• Toolbox integrated into Torque itself:
That'll just cause a catch22/'chicken and the egg' problem. That'll then require that a build of Torque 3D be dedicated to the management of Torque projects of which just doesn't make any sense and the built-in tools should only ever be associated with the currently being worked on project, not able to manipulate projects outside of the game directory if we can help it, else it'll just cause confusion: ex. "How do I switch back to my previous Torque project while in the world builder after creating and switched to the new project?".

Instead we should just stick the toolbox for the time being and as soon as you guys get the toolbox sources out I'm sure the community can take over and get it working on Mac OS X and Linux as originally intended.



• 3rd Party Request System/Issue Tracker:
Nope, Nope... Nope! We already have github's issue tracker and it is working perfectly fine and there's no way you can get any better than it short of installing and managing a software suite like Trac yourself. Yes I know Trac works with subversion, but you get my point. Not to mention we've already had to create accounts in order to comment on and do pull requests to github in the first place, and we already had to have a separate account for the GG forums. No more requiring additional accounts in order to be apart of this game engine community or else you'll just make things a lot worse.

I'm really confused as to why you guys would even consider wanting a third party issue tracker in the first place.



• Issues vs Forums:
I agree completely that actual discussions about ideas or possible features wanting to be implemented into Torque 3D should stay on the GG forums, specifically within the T3D Professional forum as T3D Beginner forum should stay on novice topics only. While the github issue tracker should be reserved for on-topic problem solving discussions with the existing code base or resolving conflicts with pull requests as to make it a lot easier for us trying to improve the game engine by monitoring and taking part in helping resolve issues.

That is all I have concerns with or comments about for now.

#2 ... what Nathan said.

#3 Yes, the One True Way to do version numbers is Major.Minor.Patch. The last one is also known as "teeny-version" in some circles :)

Bump up the last one when fixing bugs (and only that). Bump the middle one up when adding a few features (and bugfixes may ride along). Bump the first one on enormous changes, breaking data formats, completely redoing the interface, changing the name, implementing clusters of really major features.

Major version bumps can be applied when people just feel that the minor releases have made the software different enough. See the Linux being declared 3.0, for instance. It was just the time.

#4 @Nathan, about the Toolbox thing, I invite you to read the issue on Git for more context, you seem to be doing some off the point assumptions.

#5 On versioning - I support either proper Major.Minor.Patch or YYYY.MM.DD (or just YYYY.MM, ala Ubuntu). None of this Chrome/Firefox nonsense.

I'm not sure what the Toolbox is used for, apparently I don't use it very much, but I'd like to see a CMake based build system for proper cross-platformability. That way I don't have to do separate project maintenances in VS and XCode (and CodeBlocks when I'm on Linux). Just update the CMakeLists, and let CMake automate project generation.

I very much do *not* want to see binaries in the repo. That's just a huge mess waiting to happen.

#6 Here's an example of the damage done by binaries:

That project had several copies of a 3rd party library in compiled static form as part of the repository. It's out of the current version, but the pack file still has all the versions after fsck, aggressive pruning and garbage collection. The rest of the data is only a fraction of the total .git directory.

#7 I have updated the T3D wiki on GitHub and the readme with build information.

I have also drafted as CSA and will be working with the webteam to figure out how best to get it on our site in a useful fashion.

#8

Quote:
I'd like to see a CMake based build system for proper cross-platformability. That way I don't have to do separate project maintenances in VS and XCode (and CodeBlocks when I'm on Linux). Just update the CMakeLists, and let CMake automate project generation.

The PHP-based Project Generator that is included with Torque 3D is essentially a competitor to CMake (and ant) which does a very good job of keeping complex VS and Xcode projects in sync (better than CMake or ant in my experience). Since it is PHP it should be pretty easy to get it working on Linux/CodeBlocks as well.

#9 Is there a way to get the PHP code to play nice with machines that have an existing version of PHP installed?

#10 If you run the Project Generator with the php.exe/php.app that is in the included bin directory then you should be able to avoid issues with other versions of php (I *believe* generateProject.bat uses a relative path to get to the "local" php.exe).