[OSM-dev] 0.6 api - one more time

Stefan Keller sfkeller at gmail.com
Sat May 10 16:00:49 BST 2008


> handled responsible in regard to the user base. I believe osm already
> reached that point :)
I'm sorry to state with emphasis, that the OSM concept and format did *not*
reach stability yet:
It's simply lacking one of three basic geometry types, namely 'area' (or
polygon or how you name it)!
On the other hand I agree with you that changing concepts and APIs should
follow a more stable change process as we have discussed it in the initial
thread about 0.6 API.

--  S.
2008/5/10 Andreas Putzo <andreas at putzo.net>:

> Hi,
> 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 :)
> Regards,
> Andreas
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080510/708a0cc9/attachment.html>

More information about the dev mailing list