Developers

Below we cover several uniform aspects of our software to make it easy to work on projects even if you're not the original author(s).

Version Numbers

Similar to our XiniX distribution of Linux, our version numbers do not adhere to any standards that may be established. Instead we have broken this information down into four groups - (M)ajor.(m)inor.(f)ix.(s)tate. And for those who don't care for indepth knowledge of this topic, the one thing you should commit to memory is the (s)tate "octet". This will ALWAYS be either a zero (0) or a one (1) indicating a beta or stable version respectively.

Now for those who are interested in the indepth explaination of the other preceeding "octets", here we go...

* (M)ajor: is incremented when serious changes to the codebase occur. This number reflects the long-term-ness of the software version and should be incremented rarely by combining at one time as many changes as possible that fall under the below criteria. Using this method should attract developers since there's no need to constantly update their projects that rely on ours as well as to establish solid, reliable functionality of our own products. Our criteria that falls under this "octet" are:

* The files' contained API parameters change
* The code base is re-written for any reason in any language

* (m)inor: is anticipated to have single to lower two-digit numbers as well, especially in modular based projects. By restricting the changing of this number to the below criteria, we've also provided developers with increased longevity of their efforts due to all referenced API's in their code not changing - mostly. The case where code would not work would be the deletion or migration of a used API, however, we're hoping for mostly addition and not deletion. Also, it shouldn't be that complex for developers to find the alternative to their prior API call and provide a small patch to work with the updated codebase. Our criteria for numeric increases in this "octet" are:

* New API's are added to the file
* Existing API's within a file are deleted or merged (to provide an alternative to prior (relavent) functionality)

* (f)ix: will definitely be the "highest mileage" digit of the version number. This is basically the "whatever's left" changes increase this "octet". Below are just a few of the criteria, but in the real world, there's most like more:

* Bug fixes
* I/O modification
* Modification to the internal code of a function - NOT API
* Modification of "root-level" code within the file

* (s)tate: changes when the beta or stable state of the code has changed and will ALWAYS be a zero (0) or one (1) respectively.

Directory Structure

Obviously every developer is going to have their own naming conventions, directory layouts, and other unique traits within their projects. While there's nothing wrong with this as every person is a unique individual, it can pose problems when developers have to work on a codebase that's not their original work. As a result, we've put together a directory structure so that any developer can easily work on our projects. Currently we're on verion 1.6 of this layout, but further updates may occur based on unforseen/unencountered circumstances that take place. Below we'll give an explaination of the top-level directories so that everyone can have a general idea as to where files should be located.

* images: contains the various image sets installed by the user(s) of the project. This directory is responsible for one-third (1/3) of the individual GUI aspects that can be customized by artists, businesses, and other individuals. Image sets are specific to a particular layout due to the naming conventions used by that developer. Each installed image set has it's own sub-directory containing its graphics with a fixed-name symlink (Current) pointing to it that identifies which image set is currently selected for use by the user. In the event that the project must handle multiple users, instead of the single fixed-name symlink (Current), a dynamically-named symlink (members' username) will be used to accomplish this goal on a per-user basis.

* layouts: also contains one-third (1/3) of the individual customizable GUI aspects. Contained within this directory will be the .tpl (or similar format for non-php languages) files responsible for the physical placement of the form objects on the page. Please note that this parent directory contains sub-folders that include all languages used within this software. Just like the image sets mentioned above, each layout will have it's own sub-directory and uses the same symlink naming conventions to mark which one is currently selected by the user.

* libraries: is used to store the various toolsets, frameworks, and other software to increase functionality. Examples of sub-directories would be smarty, markdown, jquery, and more. It's also important to note that each used language of the project will have its own sub-directory as well - php, perl, js, etc. Those directories will contain envars (discussed below) and global (discussed below) files containing environment various and globally accessed functions for the project.

* modules:

* styling:

* temp:

* users:

ENVARS

Explain what goes in these files

Examples

Provide examples of these files

GLOBALS

Explain what goes in these files

Examples

Provide examples of these files