Welcome

On behalf of our staff we'd like to welcome you to the cliquesoft wiki. Currently there are just a handful of meaningful articles contained in this area of our site, but a bunch that need to be deleted due to spam. We'd be interested in any volunteer help from our knowledgeable users in cleaning up and co-administering our wiki as well as to assist in creating documentation for our products. For those interested, please email our staff from the "Contact Us" link on the bottom of our website. Otherwise, use the links below to access the various documentation for our distributed software. Developers can also enjoy a range of documentation below our projects list in an effort to help acclimate you to our development environments.

backup.lite backup.pro

clAPI delDup

Esesen lssmb

myVote Software

Threads video

webBooks XiniX

Developers

For those interested in helping to develop our sponsored software, we'd like to make as much information available to you as possible so that you have all the knowledge needed to begin right away! Click here to go to this area of the wiki.

 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 The major version 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 This number 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 This number will definitely be the "highest mileage."

Directory Structure

Explain the directory structure for projects

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