ReleaseProcess

Revision as of 13:26, 10 January 2014 by Rdoursenaud (talk | contribs) (Création)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Dolibarr release process

This document is a draft trying to understand what is going on to release dolibarr.

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

Officialy maintained

Descriptor

Archives

  • Gziped tar archive

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

  • Zipped archive

I'd build it from the tarball

Distribution packages

I'd make these from the release tarball.

RPM

Can't all of these be unified?

  • Generic
  • Fedora

RedHat?

  • Mandriva

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

  • OpenSuse
DEB
  • Debian

Ubuntu?

Installers

  • Windows (DoliWamp, exe)

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

Not officially maintained

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

Is this even a package format?

  • Doxygen (Developer documentation)

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

Ubuntu packages and build system?

  • Live CD

Really? What for? Demos? Looks overkill

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

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.

Building

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

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

We should also generate checksums

Add a GPG signature?

  1. ZIP release

  2. RPM releases

  3. DEB realease

  4. Windows installer release

Testing

  • ?

Pushing

  1. Tag to central repository

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

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

Credentials needed

  1. Packages to Sourceforge.net

Credentials needed

Can be automated: doc

Verifiing

  • ?

This is where checksums comes in handy

Releasing

  1. Craft announcement message

The message template should be in the repo

  1. Post announcement as a news on dolibarr.org

Credentials needed

  1. Send announcement on Social Networks

Credentials needed

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

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

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.
  • 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?
  • Wiki!
  • Doliforge (release number)!

Credentials needed

  • Release script is in Perl now, I'd like to rewrite it with Phing. Any objections ?

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 versioning and naming conventions as well as the branching system