Mapbender released / veröffentlicht

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Mapbender released / veröffentlicht

Axel Schaefer
Dear Mapbender Users and Mapbender Developers

You'll find the German version of this announcement below.

Mapbender version is available at

The Bugfix-Release contains fixes with the SearchRouter, WMS 1.3.0
services, WMC dialog and Scale Hints, among others. Please refer to the
versions-log at the Mapbender3 documentation
( for details.

Please keep an eye on the additional steps to update.

- Download: or via The TAR.GZ file is suitable for Linux
systems, because it uses symlinks in the web/bundles directory. The ZIP
file is for Windows (and Linux) and doesn't use symlinks. When in doubt,
choose the ZIP-file.

- Source code:

- for developers:

- Report bugs:

- Current Documentation:

- Installation and Update:

- Quickstart:

- Mapbender-demo:

- Sandbox with opportunity to register:

Thanks to all participants.

Some more information, just in case:

Issues and tickets

Our main issue and ticket-system is now Github: Feel free to place your
issues there.

The list for this release✓&q=is%3Aissue%20milestone%3A3.0.6.2

When a ticket arrives, we give it labels, the colorful things beside the
title. Github doesn't have a status for tickets (unless they are part of
a project) but uses labels for that. Coming from Redmine, this is a bit
unusual. So we decided to create labels for WIP (work in progress),
Testing and Resolved (which means tested and working but needs to be
merged into the main code-base).

When a ticket arrives, we have to decide if it's a bug or a feature or
both. We label it that way: Bug, Enhancement (small thing), Feature (a
bigger thing). We assign a developer (a thing the developers do
sometimes for themselves, depending on their knowledge), the developer
works on it, assigns it back, we test it. Testing is done normally at
the branch, where the fix is done. For testing we change our
composer.json from "mapbender/mapbender": "dev-release/3.0.6" to
"mapbender/mapbender": "dev-hotfix/something as release/3.0.6" or
whatever the branch is called. When the tests are OK, the branch can be
merged into the main codebase.

These are the Pull-Requests (here for version✓&q=is%3Apr%20is%3Aclosed%20milestone%3A3.0.6.2.
They are assigned to an issue and the issue is assigned to a
pull-request. Only small fixes by the core-developers are allowed
without a pull-request and can be placed directly into the release/3.0.6
branch. Pull-Request are reviewed by some developers. If they give the
OK, the pull-request is merged and closed, the old branch is deleted and
the ticket is finally closed. If they find something to improve, the
developer has to change it, we test it, the pull-request has to be updated.

What you can do:

If you encounter a bug and want to place an issue, this is how you can
help us:

- Describe step-by-step how to reproduce the issue. Place a log message
(if possible). If you have an example where to reproduce it, it's even

- Describe what you expect to happen (the expected results of the steps).

- Describe what actually happens (the actual results of the steps).

These 3 points are a good basis for bughunting.

Next steps

We will probably release another bugfix version possibly also a Depending on the development of the new features, we will
instead release a version.

For version we will include as a new feature LDAP functionality
as an optional modul. And second the support of UTF-grids like Mapserver
provides them. We will give further information for that, especially for
LDAP. We are planning to release that as an optional feature, manually
to include in composer.json, because it is not neccessary for everyone.

For version 3.1 we are working on replacing OpenLayers2 with
OpenLayers4. Addionally the feature of reusable Layerset-Instances is in
the pipe. For this I have added a concept-paper to Github:
Unfortunetaly this is only available in German, due to clarity and
understanding for the developers, because it is the base for the
requirements for the planning and development phase. Feel free to
comment. For the OpenLayers replacement we have to take the first steps
now and I guess we will create some additional tickets in Github
(depending if it will present us a clear overview of what to do).

German Version: Liebe Mapbender-Benutzer und Mapbender-Entwickler

Mapbender version is verfügbar unter

Das Bugfix-Release enthält u.a. Fixes zum SearchRouter, WMS 1.3.0
Diensten, dem WMC Dialog und bei den Scale Hints eines WMS Dienstes.
Bitte schauen Sie in das Versions-Log in der Mapbender3 Dokumentation
für Details:

Bitte beachten Sie auch die zusätzlichen Schritte zum Update.

- Download: oder über Die TAR.GZ Datei ist für Linux Systeme
geeignet, denn sie nutzt Symlinks im web/bundles Verzeichnis. Die
ZIP-Datei ist für Windows geeignet (und für Linux) und nutzt keine
Symlinks. Im Zweifel nutzen Sie einfach die Zip-Datei.

- Source-Code:

- für Entwickler:

- Melden von Fehlern:

- Dokumentation:

- Installation und Update:

- Quickstart:

- Mapbender-Demo:

- Sandbox mit Anmeldemöglichkeit:

Vielen Dank an alle Beteiligten.

Ein paar weitere Informationen:

Issues und Tickets

Unser Hauptsystem für Issues und Tickets ist nun Github: Fühlen Sie sich frei, hier
Ihre Tickets anzulegen. ;-)

Hier ist die Liste für dieses Release✓&q=is%3Aissue%20milestone%3A3.0.6.2

Wenn ein Ticket ankommt, geben wir ihm Labels, diese farbigen Dinger
neben dem Titel. Github ermöglicht es leider nicht einen Status an
Tickets zu vergeben (außer sie sind Teil eines Projektes), sondern nimmt
Label dafür. Diese können aber auch inhaltlich sein. Von Redmine
kommend, ist das zu Anfangs etwas ungewöhnlich. Wir haben uns für Labels
entschieden, die den Status widerspiegeln: WIP (work in progress, wenn
es mal etwas länger dauert), Testing und Resolved (Gelöst, was bedeutet,
dass getestet wurde und es läuft, aber noch die Schritte fehlen, um das
in die Code-Basis zu überführen).

Wenn ein Ticket ankommt, entscheiden wir uns auch, ob es ein Fehler
(Bug) oder ein Feature ist, oder beides. Wir haben Label dafür erstellt:
Bug, Enhancement (Verbesserung, also Kleinigkeiten), Features (größere
Dinge). Wir weisen einen Entwickler zu (assign, das machen die
Entwickler abhängig von ihrem Know-How auch untereinander), der
Entwickler bearbeitet das Ticket, assigned es zurück, es wird getestet.
Die Tests laufen normalerweise auf dem Branch, wo der Fix implementiert
ist. Für das Testen ändern wir also die composer json von
"mapbender/mapbender": "dev-release/3.0.6" beispielsweise auf
"mapbender/mapbender": "dev-hotfix/something as release/3.0.6" oder wie
der Branch auch immer heißt. Wenn die Tests positiv ausfallen, wird der
Branch in die Code-Basis übertragen (merge).

Dies sind dann die Pull-Requests, hier für Version✓&q=is%3Apr%20is%3Aclosed%20milestone%3A3.0.6.2.
Diese gehören zu einem Issue und das Issue Verweis auf einen
Pull-Request. Da ist Github sehr einfach zu bedienen. Kleine Änderungen
dürfen von den Kernentwicklern auch mal ohne Pull-Request in die
Code-Basis im Branch release/3.0.6 gepusht werden. Pull-Requests werden
von einigen Entwicklern überprüft (reviewed). Wenn Sie das OK geben,
kann der Pull-Request gemergt und geschlossen werden, der alte Branch
gelöscht und das Ticket schließlich geschlossen werden. Wenn Sie was zum
verbessern finden, ändert der Entwickler das, wir testen wieder, der
Pull-Request muss wieder aktualisiert werden.

Was Sie dabei tun können:

Wenn Sie einen Bug finden und ein Issue erstellen möchten, hier ist wie
Sie uns dabei helfen können:

- Beschreiben Sie Schritt-für-Schritt wie wir den Bug nachvollziehen
können. Schreiben Sie die Log-Meldungen ins Ticket (falls möglich). Wenn
Sie direkt ein Beispiel haben, wo man das Verhalten nachprüfen kann,
umso besser.

- Beschreiben Sie, was Sie erwarten, was passieren sollte (das erwartete
Resultat aus den oben beschriebenen Schritten).

- Beschreiben Sie, was stattdessen passiert (das aktuelle Resultat aus
den oben beschriebenen Schritten)

Diese 3 Punkte sind schon eine gute Basis für die Bugjagd.

Wie geht es weiter?

Wahrscheinlich wird es noch eine Bugfix-Version geben, eventuell
auch eine Je nach Fertigstellung der neuen Features werden wir
stattdessen eine Version veröffentlichen.

Für Version werden wir als neue Features u.a. die LDAP
Funktionalität als optionales Modul einbauen und eine Unterstützung von
UTF-Grids implementieren, wie sie im Mapserver verwendet werden. Wir
werden dazu noch weitere Informationen geben, speziell zu LDAP. Wir
planen das als optionales Feature, also per Hand hinzuladbar über die
composer.json, da nicht jeder es benötigt.

Für die Version 3.1 arbeiten wir gerade an der Ablösung OpenLayers2 zu
OpenLayers4. Des Weiteren steht die Wiederverwendung von
Layerset-Instanzen auf dem Programm. Dazu habe ich das Konzept auf
Github hochgeladen, dass Sie sich gerne durchlesen können
und das als Anforderungsgrundlage für die Entwicklung gilt. Für den
OpenLayers Austausch können wir nach den ersten Schritten mehr sagen,
auch dazu werden wir dann wahrscheinlich einzelne Tickets in Github
anlegen (da stellt sich nur die Frage, wie übersichtlich das dann für
uns werden wird).

Best regards / Mit freundlichen Grüßen
Axel Schaefer

Axel Schaefer
WhereGroup GmbH & Co. KG
Eifelstraße 7
53119 Bonn

Fon: +49 (0)228 / 90 90 38 - 23
Fax: +49 (0)228 / 90 90 38 - 11

[hidden email]
Amtsgericht Bonn, HRA 6788
WhereGroup Verwaltungs GmbH
vertreten durch:
Olaf Knopp, Peter Stamm
Mapbender_dev mailing list
[hidden email]