-
Notifications
You must be signed in to change notification settings - Fork 825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
switch naming back from libmapnik2 -> libmapnik (also python) #941
Comments
I'll start with my: +1 :) |
Yes, lets keep it simple : +1 |
+1 from me too. |
+1 :) I'd suggest we leave the |
+1 and +1 for rcoup idea too |
yep, good idea @rcoup |
Done in 14700db |
ACK, thanks! I'll wait a release before doing this in Debian too :) |
…n)' and remove svn traces (refs #941)
/cc @rcoup, @dpaleino, @artemp for comments.
During the large refactoring push and testing period after merging the mapnik2 codebase into mainline trunk it was very useful for development to ease the ability to run both mapnik 0.7.x and mapnik 2.x together simultaneously, and this was done by adding a
2
to the library name and the python module.We should now switch back to normal naming for the next release (2.0.1) and all that follow. The reasons are plenty:
#include </mapnik2/...>
as this would have caused a lot of breakages)The downside of course is that many users in python are now used to doing
import mapnik2
, but we can reach out to communicate this switch back and hopefully this will be a lesser evil if we move on this now.The text was updated successfully, but these errors were encountered: