Andreas, > 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 <[EMAIL PROTECTED]>: > 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 > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
