[OSM-dev] Release process for the tile rendering tool chain?

[Kai Krueger]

Hello everyone,

In the past the support for OSM software in the various package 
repositories have not been great. Either the software has not been 
included at all, or it has been rather out of date, making installing 
things like OSM tileservers unnecessarily complex. One key complaint I 
have heard from several packagers (as well as other users of the 
software) is the lack of a stable release process. Instead people just 
had to use a random snapshot from SVN / GIT and hope for the best.

With the OSM rendering tool chain increasingly widely being used, it 
seems about time to change this and try and establish some form of 
release process to indicate to users and packagers which version of the 
code is believed to be sufficiently stable for general use without 
having to expect many troubles.

As I think both osm2pgsql, mod_tile, renderd and tirex are still fairly 
simple pieces of software with not hugely active development and seldom 
commits that break backward compatibility, I think a retrospective 
tagging of git snapshots that have no known major issues as a "stable 
release" is sufficient for the time. I suspect it isn't currently 
necessary to create release branches. The development rate isn't that 
high, that not being able to commit new features during a time of 
stabilisation would be overly burdensome. It also seems acceptable, if 
there is a bug found in a stable release to ask everyone to update to 
the latest stable release, rather than patch the old stable releases. 
Although that might need to change if there are larger commits that 
break backwards compatibility. E.g. because the core database schema of 
osm2pgsql was changed, or because the protocol between mod_tile and 
renderd / tirex was changed.

Therefore I would suggest the following process:

In a period of relatively quite development, after some important / 
larger features have landed, to dedicate a git snapshot as a potential 
candidate for a stable release. Then announce the release candidate to 
the dev and tile-serving mailing list to ask for testing and or if 
anyone knows of any release critical bugs. One then waits for 1 - 2 
weeks for people to give feedback, in which time there shouldn't be any 
commits of non-release critical bugs to the repository. If there weren't 
any issues found, or only minor issues that were fixed, the release 
candidate can then be tagged as a stable release in the repository and 
its version number increased.

If I understand it correctly, this is a similar process to what Josm 
uses to declare its "tested" versions?


Thoughts, comments or suggestions about this would be appreciated.

Kai