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)
_______________________________________________
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev
