[OSM-dev] 0.6 api - one more time

Andreas Putzo andreas at putzo.net
Sat May 10 00:31:27 BST 2008


On May 05  19:49, Frederik Ramm wrote:
> > Currently, JOSM is not planned to be included in the next release
> > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474632) for exactly
> > this reason.
> I have been approached by some Debian guys about the question whether
> to include JOSM in their next stable release and I answered that given
> the usual lifetime of Debian stable releases, I fully expect 2-3
> incompatible API changes during that time and thus would not recommend
> including JOSM.
> And I don't think that's a bad thing really - every attempt at
> backwards compatibility makes stuff less maintainable. You create
> special cases that you'll end up supporting forever.
> As long as we (as a project) are young and flexible enough, let's use
> that to our advantage instead of being bogged down by more and more of
> yesterday's technology.
> > If my reading is correct, allowing backwards compatibility would be
> > fairly easy, codewise. It would be my hope that this would allow for
> > easier transitioning for things like JOSM-in-Debian: it would allow
> > backported versions of JOSM to filter in and fill the need of allowing
> > changesets without breaking the existing installed editor base. 
> Quite frankly, I have no interest whatsoever in an "installed editor
> base" that is one year old. I expect to fix many many bugs and
> implement many many new features within the next year, and it would be
> utterly demotivating to think that there are people who choose not to
> upgrade JOSM just because the year-old version is in their
> distribution and the newer ones are not!

Well, users usually just want to use software without keeping an eye
on development snapshots or upgrading their system every two week or so.
They want to be able to use software they downloaded only 6 month ago or
that comes with their distribution, is installed on a live-cd
whatsoever. Not to mention people who can only access the internet
occasionally like in areas with very low osm coverage.
I don't know how many users OSM already have but if we want to attract
more users, especially those who are not technically skilled, it should
be avoided to break their clients too often. Imagine how demotivating it
is to map a bunch of streets only to learn that they cannot upload their
work because of an API breakage. They may just step away from the
project and never come back.
This shouldn't slow down development too much of course, especially in a
young project like OSM. But there should be a point in development where
downward compatibility should be kept in mind and major changes should be
handled responsible in regard to the user base. I believe osm already
reached that point :)


More information about the dev mailing list