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
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
