OOPM:Development:Documentation:Versioning

Repository Branch/Tag Naming and Versioning

As of now, our versioning strategies for

• Repository Release:Testing Tag Naming and Versioning
• Repository Release:Proto Tag Naming and Versioning
• Repository Release:Alpha Tag Naming and Versioning
• Repository Release:Beta Tag Naming and Versioning
• Repository Release:RC (Release Candidate) Tag Naming and Versioning
• Repository Release:Stable Tag Naming and Versioning

have not yet been defined.

This is also true for ongoing development branch versioning, e.g.

• Repository Development:Maintenance Branch Naming and Versioning
• Repository Development:Implementation Branch Naming and Versioning

However, I propose that we will be using a branch/release versioning strategy
that I have devised in the past. I will provide a document/article in this wiki
on how to implement such a versioning strategy for both ongoing development and
also for actual release versioning. 

Release Assembly/Build Versioning

The multiple different platforms that we are supposed to support incorporate different versioning strategies for the assemblies deployed.

This, however, only applies to native code and libraries, or, in case of Windows and the .Net platform or any other platform incorporating Mono.

• On windows we have a quadruple representing the version number, e.g. 0.0.0.0
• On linux TBD
• On OSX TBD
• other platforms? TBD

Since we will do most of our development using the Java language, we will stick to the versioning scheme set forth by the UNO framework, if available.

Release Distribution Package Versioning

• Linux uses either rpm, or dpkg, or TBD
• Windows TBD (various installation package compilers/builders available)

OOPM Components/Services/Processes|Workflows/Process|Workflow Action Libraries/... Release Assembly/Build Versioning

• Components/Services/Process|Workflow Action Libraries

we will be using standard UNO versioning schemes for the assemblies/builds for use with the integrated extension facilities provided by the UNO

• Processes|Workflows

This highly depends on the processing engine that we will be using, I for myself would propose the JBPM