[josm-dev] GSoC application for JOSM core
Dirk Stöcker
openstreetmap at dstoecker.de
Sat Mar 19 11:02:00 UTC 2016
On Fri, 18 Mar 2016, Michael Zangl wrote:
>>> Those are the tasks I identified and of which I think that they can fill
>>> a summer - a lot of the work will be required for backward
>>> compatibility, testing and fixing bugs.
>>> https://docs.google.com/document/d/1CfGQBtsTljYg0N56sjeomZVRPTasyLoaAqVgbwDmzKs/edit?usp=sharing
>>
>> You're sure this only fills a summer?
>
> I am pretty sure I won't get even close to what I personally would like
> to do, but it should be a good starting point.
Students - Estimated times are always so optimistic. Reality usually
multiplies that by 3 or more ;-)
>From the document above it's fine to have multiple goals, but I think you
should group that into
* must be reached
* should be reached
* nice to have
so that in case of short time you can focus more on the important parts.
Also keep in mind that the constant integration approach means that you
have to write code which will or may be dropped in later steps of the
development again.
> Nice to hear. I am worried most about breaking plugins, especially the
> ones that do not use the documented API but assume some internal state
> of JOSM. I won't be able to test them all or even know of them.
JOSM has no stable API. This is a design decision which has advantages and
drawbacks. Advantage is that plugins can do nearly everything. Drawback is
that plugins do nearly everything. :-)
Our solution to this is that JOSM core comes first. We do what's
necessary. If we break used APIs, then we fix the plugins in SVN (and
github openstreetmap project). Plugins not in these repositories must be
fixed by their authors.
We try to add deprecation warnings to ease this approach, but it's not
required.
So: Caring for plugins is needed, but it should not stop necessary changes
in the core.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
More information about the josm-dev
mailing list