Hello all,
This is the first of what will hopefully become a series of posts about the technical aspects of PKP software, including tips and tricks for developers and system administrators. We hope it will be useful to anyone maintaining or customizing an OJS installation or interested in contributing. You will find all the developer blog posts gathered together on our new page for developers: https://pkp.sfu.ca/developers/
This entry will mostly be about some changes to how we use branches in github, starting with OJS 2.4.5.
The Problem
Best practices for hosting PKP software while keeping up to date with interim fixes have not been clear.
Historically, we have always maintained a page of “recommended patches” for each release of our software (e.g. the list for OJS 2.4.4-1). This can be used by a system administrator to keep on top of the common or criticial issues that we had fixed but not yet shipped in a subsequent release of the software. This list has been maintained by us manually and used sporadically in our own hosting operations.
This is useful but fairly time-consuming and error-prone. Patches needed to be applied manually, in the correct order, and it isn’t easy to keep an installation (never mind several hundred) up to date. When upgrading to a new release, it means manual review of the recommended patches that have been applied, which might be mixed in with other modifications.
Another option that we experimented with was to install OJS directly from the “ojs-stable-2_4” branch, which is actually the development branch from which 2.4.x releases are built. (Calling a development branch “stable” is a misnomer stemming from the fact that we call our 2.4.x line our “stable” line.) This works well when the ojs-stable-2_4 branch is fairly fresh from a release but in the middle of a development cycle, after new features have been added but before the testing phase works out the kinks, it can become unstable. Additionally, it’s not clear how to manage database changes since the upgrade scripts only handle upgrades between final releases gracefully.
The Solution
Starting with OJS 2.4.5, we will move all of the tracking of recommended patches into git, using some new branches.
The long-standing ojs-stable-2_4 branch will be renamed ojs-dev-2_4 to reflect its nature as a development branch, not a stable branch.
For each new release, we will create a specific “stable” branch — for OJS 2.4.5, this will be called ojs-stable-2_4_5. This branch should always be suitable for production purposes; it will receive stability fixes only, and nothing that will require database schema changes.
Our own hosting operations continue to make greater use of git, as it permits us to manage customizations. These proposed changes will further facilitate hosting with git — ensuring that an installation has all the most recent stability fixes will simply mean rebasing the modifications onto the end of the stable branch.
For users who are not hosting with git, we will continue to link from our wiki to a “recommended patches” page for each release — but in the future these will be generated directly from github.com, making sure they’re always current and applicable.
Future Steps
In our spring development sprint event, we spent a lot of time talking about automated testing. This work has continued over the summer; we have scripted a set of standardized test data and pushed more testing into the automated testing framework using Travis. Though work still continues, this has already resulted in better coverage than we’ve ever had before — including in particular PostgreSQL compatibility — and more immediate feedback when part of the test suite is broken by a buggy change.
With the OJS 2.4.5 release, a comprehensive structure for testing has been introduced and a test data set and the beginnings of a test suite have been written.
What this means is better, more consistent quality control. In addition to improving the software directly, it means we’ll have more options for our software release cycle — completing and testing a release will no longer be a 2-month process with considerable developer time spent on manual testing.
Feedback
We depend on a number of groups, particularly our Technical Committee, for guidance and feedback. We’re always happy to hear from the broader community. If there’s something we could do to further refine this process and make your life easier, let us know!
Regards,
Alec Smecher
PKP Technical Architect
