New release of GAP 4.7.9 was announced in the beginning of December 2015. In this guest post (reproduced from here), Olexandr Konovalov tells about his work from research software engineering perspective.

This week I was mainly wearing my Research Software Engineer (RSE) hat. RSE support for the GAP system has three related strands: development of the core GAP system; support of package authors and other GAP users; training future users and contributors to the system. They are all important for the thriving community of users and developers, and this week I’ve done something to advance each of them.

First, I’ve prepared a new release of GAP 4.7.9.We use Jenkins CI to run nightly and weekly regression tests and to automate wrapping release candidates. With such automation, we can release as often as needed – for example, if there is an urgent bugfix or a major package update, then after passing the weekly testing cycle we would have all archives for the GAP source distribution ready. This week the plan was to make a new minor release – not because of the changes in the core GAP system (there were not many of them, since all major efforts are now happening in the master branch to be released in GAP 4.8), but mainly to deliver updates of 28 out of 119 packages currently redistributed with GAP that were published since June (previous minor release).

My week began with the evaluation of weekly tests of all three kinds of releases: next minor release GAP 4.7.9, next major release GAP 4.8.1, and update release GAP 4.7.8 (an update release is the one which contains the same core system as the last minor release, but newer versions of GAP packages). Of course, the main focus was on GAP 4.7.9. I was pretty sure that it passes the tests, since I haven’t got any failure notifications and nightly tests were looking good last week, but still performed some manual checks, inspecting the logs and trying to run the Windows version manually in addition to its Jenkins tests). All went well, but it was not yet time to publish – since November 2014, we also provide GAP installer for Windows as one of the standard GAP distribution format. It’s build is only semi-automated, so I had to complete the procedure using NSIS and then test the installer manually.

After that, it was finally the time to make all the archives public – that’s exactly the moment of the release! We will never reuse the same version number for any GAP archive which is already in the public access. The same very strict rule applies to GAP packages – updated versions will be automatically rejected if the package is changed but the version number remains the same.

After the release happened, I’ve edited the Mercurial published the changes on the GAP website and announced the release. I’ve also updated some of the alternative installations, listed here: BOB and Homebrew. These two are installers that retrieve, unpack and build GAP and all packages. This time there were no changes in the build procedure, so it was easy: I only had to point the installers to the new archives. My pull request on GitHub to update the Homebrew formula for GAP passed their tests with Travis CI and was accepted in just a couple of hours.

Working on all this, I haven’t done much for the GAP 4.8 release, except fixing some examples in test files and manuals to stop nightly tests from failing, but I hope to do more in the coming weeks and then during the GAP Coding Sprint and GAP-SageMath days in January. Our plan for GAP 4.8 is to offer the beta-release to package authors to test and upgrade their packages, and collect all updates by February 1st, 2016, and we hope to release GAP 4.8 shortly after that.

And here comes the second strand of RSE support: integrating GAP packages into the system. Packages may extend GAP, for example, by implementing new functionality, providing databases of algebraic objects, or by adding infrastructural features like interfaces to other systems. Using Jenkins, we check for updated versions of packages each weekday and immediately run the regression tests. This ensures that most of issuer are detected and reported back to package authors quickly. Typical problems are incompatibility with the system by breaking its standard tests, and incompatibility with other packages which can not be both loaded simultaneously. A problem that is harder to detect is whether a package or a change in the core system breaks another package – at the moment, only 57 out of 119 packages provide standard regression tests, and I was advocating for using this practice here. I’ve been also looking at several more packages updated this week, checked that one of them fixed the previously reported to its author problem, and briefly looked at a prototype of another package that may shortly be submitted for the redistribution with GAP to advise its authors on the next steps. Releasing new version of GAP also required some maintenance of the package update system to mark package versions that were included into the next GAP release as stable – you can see a report on the current latest and stable versions of packages on this Wikipage.

Finally, to help new users, I’ve started to revise my Software Carpentry lesson “Programming with GAP“. This lesson is intended for GAP beginners and has been beta-tested at the Software Carpentry Workshop that we run in Manchester as a part of the First CoDiMa training school in Computational Discrete Mathematics. I am trying to clarify some things to help those reading it for self-study and/or to be taught by others. If you would like to contribute to its further development, issues and pull requests on GitHub are most welcome!