This documentation is open to be edited by all CODESYS Forge developers. It can be used to share global information, which is of interest for developers of differnt projects.
It's contents is not ment dogmatic and provides the reader with enough tips / tricks to help write code which is clearly readable and quicker understood by the community.
Use the CODESYS programming system in the latest version. It's use is completely free.
You can the program every CODESYS programmable PLC with it, or use the 2h Demo of one of the SL runtimes:
The demos are running 2h and can be restarted as often as you want.
You should use SVN when you want to have a good version control system with CODESYS projects, and if you want to publish them on CODESYS Forge.
CODESYS SVN can be freely used with CODESYS Forge. But we reconnend to use the tool cforge, as it improves the workflow with CODESYS Forge pretty much.
When it comes to library compatibility, the rule is really as easy as that:
"The CODESYS version of the user should be greater or equal to the format of the library."
Things like the Compiler Version, Visu Profile, etc. will usually be used from the final project, not from the library.
Offcourse there are some known exceptions;
* ;
* ;
* etc
The following version scheme suggestion is empirical in nature;
v0.0.0.1 Initial version: Your first library / project in beta stage
whenever you bugfix, just count up..
v0.0.0.2 Bugfixes/coding version 2
v0.0.0.49 Bugfixes/coding version 49
whenever you have tested a complete stable internal version
v0.0.1.0 your first stable version (tested)
v0.0.1.3 your first stable version (tested) with some bugfixes
v0.0.2.0 your second stable version (tested)
v0.0.3.11 your third stable version (tested) with more bugfixes
whenever you have software which you have tested externally (public beta)
v0.1.0.0 your first public beta version (tested/ publicly released)
v0.1.0.2 your first public beta version (tested/ publicly released) with some bug fixes
v0.2.0.0 your second public beta version (tested/ publicly released)
Whenever you have a stable public aplha release;
v1.0.0.0 Your first alpha released version
v1.0.0.6 Your first alpha released version with some bugfixes
v1.1.0.9 An alpha released version with a beta tested/released component and some bugfixes
v2.0.0.0 Your second alpha released version
As seen, this versioning scheme leaves "room" for (arbitrarily) smaller or larger code updates while also providing a clear overview of the development progress.
Offcourse other versioning scheme's are possible (provide examples)