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.

IMPORTANT Unoidl no longer supports the @version tag for versioning individual components a/o services a/o interfaces. I wonder how we introduce version based recognition of individual components our system requires, or, when downloading available future extensions, how we will check against the currently installed version of our software system in order for us to introduce some kind of (version) dependency management, considering that some future extensions might rely on other extensions to be available as well...

See http://api.openoffice.org/docs/DevelopersGuide/Appendix/IDLDocumentationGuide/IDLDocumentationGuide.xhtml for more information on the deprecated @version tag.

However, future plans state that there will be versioning applied to uno based component assemblies and provably also their sources, see http://www.freesoftwaremagazine.com/node/1440 for more information on future plans.

Release Distribution Package Versioning

• Linux uses either rpm, or dpkg, or TBD
  • for linux we must go multiple paths, namely the binary-rpm, source-rpm, binary-deb, source-deb way
  • for dpkg based packages there exist multiple integrations for maven in order to be able to automate the process of creating those installation packages

in fact, there is one that was adopted by myself, see https://v-endor.abstraxion.org/wiki/org/codehaus/mojo/deb-maven-plugin for more information, however, due to maven's java nature, it supports only jar's and similar packaging concepts such as wars and so on

thus we might use it with the extension components that need to be packaged and installed somehow

• Windows TBD (various installation package compilers/builders available)
  • for windows we could use either InnoSetup or the setup utility that is used to ship OOo

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