This page documents Evolution's release process and schedule.

Release Process

Pre-Release Checklist

Note, I've found these pre-release steps are easier to do on the weekend prior to a release. Less risk of unforeseen issues on the tarball due date. --MatthewBarnes

* Rebuild all modules from scratch (run git clean -xdf first if necessary). Either fix or file bugs for any issues, including compiler warnings. Build and install modules in the following order to satisfy dependencies (modules shown side-by-side can be built in parallel):

• 1st	evolution-data-server
  2nd	evolution
  3rd	Extension Modules (ews, etc.)

* Run make check on all modules and fix any errors. This often involves updating POTFILES.in as it is frequently overlooked during development.

* Make sure API documentation is up-to-date for modules that use Gtk-Doc. In particular, check the foo-undeclared.txt and foo-unused.txt files for new or obsolete symbol names and update the corresponding foo-sections.txt file appropriately.

* For unstable releases only: If you can, build modules against the latest stable and unstable GNOME platform releases (GLib, GTK+, etc.). Evolution should always build successfully in either environment. Building against stable libraries (e.g. GTK+ 2.16) helps catch premature usage of new API without proper version check macros (e.g. GTK_CHECK_VERSION). Building against unstable libraries (e.g. GTK+ 2.17) -- or better, git master HEAD -- helps catch recently deprecated API that may affect us, since we generally build with deprecated API disabled (e.g. GTK_DISABLE_DEPRECATED).

* Actually use the software for a day or two prior to release to make sure there are no glaring issues. The more developers and testers that take part in this the better.

Tarball Distribution

The source code and documentation should be ready for release at this point. This section deals with preparing and uploading the official release tarballs.

* MaintainersCorner/Releasing documents the basic tarball distribution process for GNOME modules. Note we use post-release version incrementing, so versions in configure.ac files should be incremented immediately after the release is tagged and tarballs are uploaded. Also note that we now automatically generate the ChangeLog file in tarballs since moving to git for version control, so disregard the bits about adding ChangeLog entries.

* Adding NEWS entries to each package is the most tedious step. Scripts to help automate the process would be most appreciated. Again, we do not maintain ChangeLog files anymore so you'll want to look at the commit history since the last release. The following command will get you started. Use your best judgment to pick commits worth mentioning. Skip frivolous commits like typo and whitespace fixes.

git log --pretty=format:"[%h] %s (%an)" LATEST_MODULE_TAG.. | tac

* In NEWS entries, list bugs fixed in this release. If the module has multiple Bugzilla components, group the bugs by component. If the commit message for the bug fix differs from the bug's summary in Bugzilla, use the Bugzilla summary. (Developers are responsible for making sure the Bugzilla summary is accurate and meaningful, and using it as your commit message ensures this.)

Post-Release Updates

* For stable major releases only: Add new data for the addressbook data migration test suite. Only for new stable releases where micro version is 0, such as 3.12.0, 3.14.0 etc. This should be done before any post-release version increment.

* Remember to increment the version in configure.ac for each package.

* Update the latest stable or unstable version shown in the #evolution IRC channel topic, or ask one of the channel operators to do it.

* Update the tarball file links in ../#Get_the_Source_Code.

* Update the Release Schedule below.

Branching

After releasing a major new stable version such as 3.2.0, a new branch (so-called "stable" branch) should be created for each Git module. The branch is named after the upcoming major GNOME release. So for GNOME 44 the stable branch name would be "gnome-44". Maintenance of the stable version then continues on the stable branch, while development for the next six-month cycle resumes on the module's "master" branch.

Detailed instructions for creating and pushing the new Git branch are on the MaintainersCorner page in the Branches section. I would advise, however, rather than branching off the HEAD revision of "master", as the example there shows, to instead use the module's release tag that you should have just created. It's just less error-prone that way.

So for Evolution 3.44.0, for example, the procedure would be:

git branch gnome-44 3.44.0
git push --tags origin gnome-44
git branch -d gnome-44
git checkout -b gnome-44 origin/gnome-44

Tarball Corrections

Despite our best efforts, sometimes the released tarball is flawed and must be corrected immediately. The procedure for correcting a flawed tarball is to release a new tarball with a .1 appended to the version number (or .2 if the first correction failed to address the flaws, etc.). For example, if the evolution-2.28.3 tarball were flawed, we would release a corrected tarball named evolution-2.28.3.1.

When preparing a corrected tarball, the fourth number in the version string should be appended to the CMakeLists.txt project command VERSION argument, like so:

project(evolution
-       VERSION 3.25.92
+       VERSION 3.25.92.1
        LANGUAGES C)

All the rest is the same as with other releases.

Condensed Release Process

This is a condensed release process as command by command cook book. Outputs of some commands require manual changes, especially the one with NEWS update, where the output is only prepared for further manual changes. It's written for evolution-mapi, but it can be used for evolution-data-server, evolution and evolution-ews as well.

* pre-release checkout check

   $ git pull && git status

* update NEWS file (set correct previous version in USEGITTAG):

   $ export USEGITTAG=3.. && \
     echo -e "All commits:\n" >../a.txt && \
     git log --pretty=format:"[%h] %s (%an)" --reverse $USEGITTAG.. &>>../a.txt && \
     echo -e "\n\nDivided commits:\n" >>../a.txt && \
     echo -e "\nBug Fixes:" &>>../a.txt && \
     (git log --pretty=format:"%x09%s (%an)" --reverse $USEGITTAG.. `ls -a -I . -I .. | \
        grep -v -w po | grep -v -w help` | grep -E -i "Bug|I#|M!" | sort &>>../a.txt || \
        echo "" &>>../a.txt) && \
     echo -e "\nMiscellaneous:" &>>../a.txt && \
     (git log --pretty=format:"%x09%s (%an)" --reverse $USEGITTAG.. `ls -a -I . -I .. | \
        grep -v -w po | grep -v -w help` | grep -E -i "Bug|I#|M!" -v &>>../a.txt || \
        echo "" &>>../a.txt) && \
     echo -e "\nTranslations:" &>>../a.txt && \
     (git log --pretty=format:"%x09%an ()" --reverse --stat $USEGITTAG.. \
        po/ &>>../a.txt || echo "" &>>../a.txt) && \
     ((test -d help && git log --pretty=format:"%x09%an ()%s (%an)" --reverse \
        --stat $USEGITTAG.. help/ &>>../a.txt) || echo "" &>>../a.txt) && \
     unset USEGITTAG
   $ gedit NEWS ../a.txt

• when doing a new 3.x.0 release, then also:

        - edit ChangeLog file and correct the branch name from 'master' to 'gnome-4y'
        - in evolution, edit flatpak/org.gnome.Evolution-stable.json and correct
          the branch names and versions it will be building

* commit NEWS changes (set correct version)

   $ git diff
   $ git add -u && git commit -m "NEWS update for 3.."

• if anything broke:

       $ git reset HEAD^

• edit the changes

  repeat this step from: git add -u &&....

* disttest

   $ cd _build/ && \
     CFLAGS='-g -O2 -Wall -Wno-deprecated-declarations' make disttest >/dev/null && \
     cd ..

* verify NEWS changes again

   $ git diff HEAD^ && git status && git log --pretty=format:"[%h] %s (%an)" HEAD^..
   $ git push

* tag the release (set correct version)

   $ git tag -a 3.. -m "Tag 3.. release"
   $ git push origin 3..

• when doing a new 3.x.0 release, then also:

        - create a new stable branch:
            $ git branch gnome-4y master
            $ git push origin gnome-4y
            $ git branch -d gnome-4y
        - verify which branch is still active ('master' should be):
            $ git branch
        - correct ChangeLog URL back to 'master'
        - in evolution-data-server and evolution in CMakeLists.txt bump
          the BASE_VERSION variable to the next stable version
        - do the "post-release version bump" also in the new gnome-4y branch

* post-release version bump

   $ nano CMakeLists.txt
   $ git diff
   $ git add -u && git commit -m "Post-release version bump" && git push

* upload tarball

   $ scp _build/evolution-3. master.gnome.org:
   $ ssh master.gnome.org
   $ ls
   $ ftpadmin install 

* update channel topic in Libera.Chat #gnome-evolution with the released versions

* when doing a new 3.x.0 release, then, once all modules are released, update the main Wiki page with the released version.

Release Schedule

Evolution follows official GNOME release schedule, which can be found here.

An iCal file is available at https://www.gnome.org/start/unstable/schedule.ics.
This webcal schedule link might make subscribing easier.