-
Notifications
You must be signed in to change notification settings - Fork 48
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
Add ability to find latest applicable mapnik version #108
Comments
One question: are we sure we want to have versions for patches? A patch means that the API has not changed, and thus, given that the mapnik-reference describes the API, I'm not sure it makes sense to have versions for Mapnik patches here. Thoughts? |
@yohanboniface It is possible that a patch release could introduce new features but not disrupt any existing API features, so yes. |
Okay. It feel we could find a simpler workflow, but let's go this way for now. :) |
This also: - dynamically builds the available versions by listing the versions directories. - introduces module.latest, that point to the latest version id available Using "semver" module, this will also allow much advanced loading syntax (like ranges, carret, star or x…).
This also: - dynamically builds the available versions by listing the versions directories. - introduces module.latest, that point to the latest version id available Using "semver" module, this will also allow much advanced loading syntax (like ranges, carret, star or x…).
landed in 08437ab |
Currently it is required that every single version of Mapnik have its own folder in mapnik reference, however, with the quicker iteration of mapnik releases there may not always be any changes to mapnik-reference required. Therefore mapnik-reference should attempt to auto detect a version if the folder does not exist.
The auto finding of another version of mapnik should only find the latest patch version that is lower then or equal to the version of mapnik.
Therefore:
If our versions in mapnik-reference are:
3.0.1
would use3.0.0
3.0.3
would use3.0.3
3.0.4
would use3.0.3
3.1.0
would fail because there is not a3.1.0
/cc @yohanboniface
The text was updated successfully, but these errors were encountered: