ReleaseProcess
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
Descriptor
Archives
- 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.
RPM
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
DEB
- Debian
RD: Ubuntu?
Installers
- 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.
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
- Launchpad (https://launchpad.net/dolibarr)
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
- Packagist.org (Compser)
Tentative process
Early announcement
- 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
- Update version numbers in source code, ChangeLog and PAD files
- Commit and Tag version
RD: Better be a signed tag
Checkout tag to a test directory
Play unit tests
Play UI tests
If all is OK
Checkout tag to a build directory
Clean build directory (i.e. remove stuff that won't go into release. Includes devolopment tools, samples, test results, git repo itself, etc.)
Fix rights
TAR reference release
RD: We should also generate checksums
RD: Add a GPG signature?
ZIP release
RPM releases
DEB realease
Windows installer release
Testing
- ?
Pushing
- Tag to central repository
RD: Credentials needed. This won't get along with a pull request!
- Packages, Artifacts (Checksum(s), signature(s)…), ChangeLog and PAD files to dolibarr.org (/home/dolibarr/wwwroot/files)
RD: Credentials needed
- Packages to Sourceforge.net
RD: Credentials needed
RD: Can be automated: doc
Verifiing
- ?
RD: This is where checksums comes in handy
Releasing
- Craft announcement message
RD: The message template should be in the repo
- Post announcement as a news on dolibarr.org
RD: Credentials needed
- Send announcement on Social Networks
RD: Credentials needed
RD: Should all be automated through their respective APIs
- Send announcement on Mailing lists
dolibarr-user, dolibarr-dev, dolibarr-foundation
- Send announcement on Forum
RD: This should be a sticky in the appropriate category (which?)
RD: Credentials needed
- Create version on this wiki
RD: Credentials needed
- Create version in Doliforge
RD: Credentials needed
Misc. Questions
RD
- 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