From Dolibarr ERP CRM Wiki
Jump to navigation Jump to search

Full release process is today done automatically and documented on page FAQ_Release_process

This page is a draft for evolution requets.

Dolibarr release process

This document is a draft.

The intention is to document what needs to be done to release Dolibarr.

RD: I intend to use it as a base to revamp the whole releasing process.

Officialy maintained



  • Gziped tar archive

Actually uses the .tgz extension, I'd prefer the more common .tar.gz

SO: In my opinion it would be even better if we could use .tar.xz

  • Zipped archive

RD: I'd build it from the tarball

Distribution packages

RD: I'd make these from the release tarball.


RD: Can't all of these be unified?

LD: This is what Generic below is for but specific versions are needed for distro integration

RD: I think that Debian integration is ongoing, what about other distros?

Isn't this the distribution package maintainer responsibility, not the release managers?

  • Generic
  • Fedora

RD: RedHat?

  • Mandriva

RD: Is this really needed? I mean who still uses mandriva these days?

  • OpenSuse
  • Debian

RD: Ubuntu?


  • Windows (DoliWamp, exe)

RD: This one is the most involved. We need a better spec of the process.

Not officially maintained

RD: Need volunteers?

These packages are not officially maintained but are in the source tree. Maybe we'd want to have them work one day or another.

  • APS
  • MacOS X installer (DoliMamp, dmg)
  • DOAP

RD: Is this even a package format?

  • Doxygen (Developer documentation)

RD: Again, not a package format, but this should certainly be published somewhere for each released version

RD: Ubuntu packages and build system?

  • Live CD

RD: Really? What for? Demos? Looks overkill

RD: This one is pretty cool. Looks like we could leverage its capabilities to automate the builds of our Linux distribution packages. Credentials needed

  • Virtualmin installer
  • Proxmox Appliance

Nice to have

RD: Releases that don't exist just yet but would help reaching farther IMHO

  • GitHub releases
  • (Compser)

Tentative process

Early announcement

  1. Post to dolibarr-dev intention to package. Ask testers to test. Ask translators to update their translations. Fix release date allowing at least one week for people to do their tasks.


  1. Update version numbers in source code, ChangeLog and PAD files
  2. Commit and Tag version

RD: Better be a signed tag

  1. Checkout tag to a test directory

  2. Play unit tests

  3. Play UI tests

If all is OK

  1. Checkout tag to a build directory

  2. Clean build directory (i.e. remove stuff that won't go into release. Includes devolopment tools, samples, test results, git repo itself, etc.)

  3. Fix rights

  4. TAR reference release

RD: We should also generate checksums

RD: Add a GPG signature?

  1. ZIP release

  2. RPM releases

  3. DEB realease

  4. Windows installer release


  •  ?


  1. Tag to central repository

RD: Credentials needed. This won't get along with a pull request!

  1. Packages, Artifacts (Checksum(s), signature(s)…), ChangeLog and PAD files to (/home/dolibarr/wwwroot/files)

RD: Credentials needed

  1. Packages to

RD: Credentials needed

RD: Can be automated: doc


  •  ?

RD: This is where checksums comes in handy


  1. Craft announcement message

RD: The message template should be in the repo

  1. Post announcement as a news on

RD: Credentials needed

  1. Send announcement on Social Networks

RD: Credentials needed

RD: Should all be automated through their respective APIs

  1. Send announcement on Mailing lists

dolibarr-user, dolibarr-dev, dolibarr-foundation

  1. Send announcement on Forum

RD: This should be a sticky in the appropriate category (which?)

RD: Credentials needed

  1. Create version on this wiki

RD: Credentials needed

  1. Create version in Doliforge

RD: Credentials needed

Misc. Questions


  • More projects are moving to tar.xz releases, shan't we join the boat?
  • Shouldn't we use native environments to build distribution packages and windows installer? Vagrant maintained virtual build and test machines would be neet.

LD: More then 80% of users prefer to use installer, and 60% of dowload are for wamp installer, so we must keep native distribution packages.

  • Arch Linux package could be adopted and made up to par with other distro's
  • Shouldn't we publish also on GitHub since it's one of our homes now? This can be fully automated with the API
  • Is there other announcements to be made?
  • Release script is in Perl now, I'd like to rewrite it with Phing. Any objections ?

LD: No, it would be better to have only php tools.

Misc. Notes

  • Directory structure for resulting binaries should be:
├── generic
├── package_aps
├── package_debian-ubuntu
├── package_mac
├── package_rpm_generic
├── package_rpm_mandriva
├── package_rpm_opensuse
├── package_rpm_redhat-fedora
└── package_windows
  • We need to define the versionning and naming conventions as well as the branching system