software_versions python module “stable” release

10 months ago, in the company I work for, we have started (as a part of some process automation)  working on the software_versions python module. To make a slightly long story very short: it’s a module which is meant to be used for checking the current stable versions of various open source vendors software. Right from the start it we’ve released it as open source project.

To make short story bit longer:

The logic behind it is quite simple: for some client reports, we are expected to put down into a report latest available (via RHN and directly by software vendors) supported (stable) versions of the software which affects our clients’ systems.

While RHN support is a part of a RHN python module with wider functionality (which will take some time to be released to public, it’s still quite a hack), module for checking latest vendor-provided versions was a quick one.

Right now, in its first stable release, software_versions checks latest vendor provided stable versions for these fine pieces of software:

  • Sendmail
  • Cyrus-IMAPD
  • Apache HTTPD project (Apache web server)
  • Squid (proxy :-))
  • CanIT
  • PostgreSQL
  • Squirrelmail
  • OpenLDAP
  • PHPLDAPadmin
  • Postfix
  • Nginx
  • MySQL
  • ProFTPD
  • VsFTPD

At times, module can be broken. That’s because there is no unified method of checking for latest software versions (most of the open source vendors don’t provide even the RSS feed for their releases), so to keep things simple we went with seemingly danger method for checking: we are, indeed, parsing the web sites for these projects, and “grepping” (well, regexping…) software versions from the HTML code.

That might look like the worse way to cope with this issue. But, in the long run it proved good enough. Any other approach would require wide (and by that I mean way too wide) range of depencies for this module. Open source projects mentioned above simply vary too much. For example, code base of all these projects is maintained with too many DCVS mechanisms of choice to make checks properly for each one, but even if they all ran on, for example, git it wouldn’t make things any easier to detect stable versions from the repositories. Each time has its own method and culture of branching, merging and handling the releases.

RSS feeds were another no-go, on most sites there simply aren’t any. Doing some sites through RSS and others by parsing their web pages didn’t make much sense either.

Relying on open source portals was also impossible, because they often simply miss making the news out of new software releases. And even if they were following all the projects religiously, parsing out the freely formed news from portal feeds is more of a challenge than parsing more-less static structure of open source vendor sites.

So there you go. But have no (much) fear! During this almost-a-year of production use, software_versions rarely broke. I admit, once or twice it did break due to unconsistent updates of vendor sites, which broke HTML in a way we couldn’t possibly expect and implement into regexp rules. But other times it was simply due to not-flexible-enough regexp rules. I really consider rules are now defined as good as they can be, so today we have finally tagged this project ‘1.0’.

I hope you enjoy this one.

Published by Vedran Krivokuca

A developer living and working in Germany. Wannabe opensource contributor. Feeling strong of some social issues.

Leave a comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This site uses cookies. Find out more about this site’s cookies. Dismiss