Do you want to know when a new version of your favorite project is released? Do you want to make your job as packager easier? If so, this article is for you. It introduces you to the world of release-monitoring.org. You’ll see how it can help you catch up with upstream releases.

What is release-monitoring.org?

The release-monitoring.org is a combination of two applications: Anitya and the-new-hotness.

Anitya is what you can see when visiting release-monitoring.org. You can use it to add and manage your projects. Anitya also checks for new releases periodically.

The-new-hotness is an application that catches the messages emitted by Anitya. It creates a Bugzilla issue if the project is mapped to a Fedora package.



How to use release-monitoring.org

Now that you know how it works, let’s focus on how you can use it.

Index page of release-monitoring.org

First think you need to do is to log in. Anitya provides a few options you can use to log in, including the Fedora Account System (FAS), Yahoo!, or a custom OpenID server.



Login page

When you’re logged in, you’ll see new options in the top panel.

Anitya top panel

Add a new project

Now you can add a new project. It’s always good to check whether the project is already added.

Add project form

Next, fill in the information about the project:

Project name – Use the upstream project name

– Use the upstream project name Homepage – Homepage of the project

– Homepage of the project Backend – Backend is simply the web hosting where the project is hosted. Anitya offers many backends you can chose from. If you can’t find a backend for your project, you can use the custom backend. Every backend has its own additional fields. For example, BitBucket has you specify owner/project.

– Backend is simply the web hosting where the project is hosted. Anitya offers many backends you can chose from. If you can’t find a backend for your project, you can use the custom backend. Every backend has its own additional fields. For example, BitBucket has you specify owner/project. Version scheme – This is used to sort received versions. Right now, Anitya only supports RPM version scheme.

– This is used to sort received versions. Right now, Anitya only supports RPM version scheme. Version prefix – This is the prefix that is stripped from any received version. For example, if the tag on GitHub is version_1.2.3, you would use version_ as version prefix. The version will then be presented as 1.2.3. The version prefix v is stripped automatically.

– This is the prefix that is stripped from any received version. For example, if the tag on GitHub is version_1.2.3, you would use version_ as version prefix. The version will then be presented as 1.2.3. The version prefix v is stripped automatically. Check latest release on submit – If you check this, Anitya will do an initial check on the project when submitted.

– If you check this, Anitya will do an initial check on the project when submitted. Distro – The distribution in which this project is used. This could be also added later.

– The distribution in which this project is used. This could be also added later. Package – The project’s packaged name in the distribution. This is required when the Distro field is filled in.

When you’re happy with the project, submit it. Below you can see how your project may look after you submit.

Project page

Add a new distribution mapping

If you want to map the project to a package on a specific distribution, open up the project page first and then click on Add new distribution mapping.

Add distribution mapping form

Here you can chose any distribution already available in Anitya, fill in the package name, and submit it. The new mapping will show up on the project page.

Automatic filing of Bugzilla issues

Now you created a new project and created a mapping for it. This is nice, but how does this help you as a packager? This is where the-new-hotness comes into play.

Every time the-new-hotness sees a new update or new mapping message emitted by Anitya, it checks whether this project is mapped to a package in Fedora. For this to work, the project must have a mapping to Fedora added in Anitya.

If the package is known, the-new-hotness checks the notification setting for this package. That setting can be changed here. The last check the-new-hotness does is whether the version reported by Anitya is newer than the current version of this package in Fedora Rawhide.

If all those checks are positive, the new Bugzilla issue is filed and a Koji scratch build started. After the Koji build is finished, the Bugzilla is updated with output.



Future plans for release-monitoring.org

The release-monitoring.org system is pretty amazing, isn’t it? But this isn’t all. There are plenty of things planned for both Anitya and the-new-hotness. Here’s a short list of future plans:

Anitya

Add libraries.io consumer – automatically check for new releases on libraries.io, create projects in Anitya and emit messages about updates

Use Fedora package database to automatically guess the package name in Fedora based on the project name and backend

Add semantic and calendar version scheme

Change current cron job to service: Anitya checks for new versions periodically using a cron job. The plan is to change this to a service that checks projects using queues.

Support for more than one version prefix

the-new-hotness

File Github issues for Flathub projects when a new version comes out

Create pull requests in Pagure instead of filing a Bugzilla issue

Move to OpenShift – this should make deployment much easier than how it is now

Convert to Python 3 (mostly done)

Both

Conversion to fedora-messaging – This is already in progress and should make communication between Anitya and the-new-hotness more reliable.

Photo by Alexandre Debiève on Unsplash.