8.3. Upgrading

Upgrading to newer versions of Scmbug is possible. It first requires understanding the issues involved in running non-matching versions of the Glue and Daemon.

8.3.1. Issues

The communication protocol between the Glue and the Daemon is upgraded and is backwards-incompatible when the minor version number of Scmbug increases. For example, SCMBUG_RELEASE_0-1-x and SCMBUG_RELEASE_0-2-x are not compatible, but SCMBUG_RELEASE_0-2-1 and SCMBUG_RELEASE_0-2-8 are.

Tip

During SCM events activity, if the Glue detects an incompatible version of the Daemon, it will refuse to continue.

Warning

Running incompatible versions of the Glue and Daemon can result in developers being locked out of an SCM repository.

For example, when using CVS it could result in the integration failing to commit any changes, leading into a dead-end. This would prohibit disabling the Glue in its entirety, and require manually editing the repository locally using RCS commands. Certainly, an SCM repository can always be brought back to a working state by a competent administrator.

Since version SCMBUG_RELEASE_0-3-3, the Glue Installer is able to safely upgrade the integration to newer versions. It first completely disables all SCM hooks installed by Scmbug, upgrades the Glue code, and then enables the hooks. During the last step, the Daemon does not need to be contacted, since the hooks are not yet active.

Note

If you understand the implementation internals of Scmbug you will be able to determine whether a new feature is implemented in the Glue or the Daemon, and upgrade only the Glue or only the Daemon.

One example where you might not want to upgrade both the Glue and Daemon is if you have a lot of SCM repositories and you need a new feature that has been implemented only on the Daemon. Upgrading only the daemon is a lot easier than first upgrading all repositories. Another example would be upgrading only the Glue of a single SCM repository if you need a new Scmbug feature only in that repository.

Tip

If in doubt, upgrade everything.

8.3.2. Steps

Upgrading to a newer version of Scmbug requires first upgrading the Glue and then the Daemon, by carrying out in order the following steps.

8.3.2.1. Glue Upgrading

  • Upgrading Scmbug: Install newer versions of the packages scmbug-common, scmbug-doc, and scmbug-tools, as shown in Section 8.2.1.

    Tip

    If one of the SCM repositories that will be upgraded is hosted by Subversion, then these packages must also be installed on the machine hosting the Subversion repository. As explained in Section 7.1.2, local repository access will be required in the next step to upgrade the integration glue.

  • Upgrading all SCM repositories: Run the Glue Installer once per SCM repository with respective arguments to upgrade to a newer version of the Glue, as described in Section 7.1.

    Warning

    The Glue Installer will display changes between the existing and updated glue configuration file in diff format. Manually merge-in any updates to the glue configuration file as needed. Failure to do so could result in the Glue failing to work.

8.3.2.2. Daemon Upgrading

  • Upgrading the Integration Daemon: After all SCM repositories have been upgraded, upgrade the Integration Daemon by installing a newer version of the packages scmbug-common and scmbug-server, as shown in Section 8.2.5.

    Warning

    Ommiting to upgrade an SCM repository before upgrading the Daemon could result in developers being locked out of the repository.

    Should that happen, it's possible to downgrade to the previous version of the Daemon, upgrade the repository as described in Section 8.3.2.1, and upgrade the Daemon again. During this process, all other upgraded SCM repositories will be unable to accept activity, since the Glue will detect an incompatible Daemon and refuse to continue.