-
Notifications
You must be signed in to change notification settings - Fork 822
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
Releasing v5.9.0 #4981
Comments
I did a review access tags. I really want to get away from the messy incorrect way we currently handle access tags, but I think there are substantial technical changes needed. |
Is it worth reconsidering #3012 ? I'm not an expert in Github actions, but I think it would now be feasible to include the XML produced in the CI testing as an artifact? This would significantly simplify installation. |
#3012 has been waiting for someone to develop a practical solution since 2018. I think it would be nice to solve this but i don't see a particular need for it now for this release. |
I see no relation between #3012 and this release. Someone can develop the github actions that saves artifacts if they want and it'll start running immediately without waiting for a release. Also we would generally not wait for an issue to be resolved that doesn't at least have a PR! |
The only connection in mind was that releases can be bundled with artifacts, such as the
Indeed, but knowing that a PR would be both welcome and feasible might inspire a contribution! |
For us releases so far are just tags in git - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/RELEASES.md
Yes, #3012 is open and we'd welcome a solution for it. Some comments have been provided what methods for implementing that might be feasible and what are not but i'd suggest anyone who wants to work on that to discuss their planned approach before investing work in implementation. |
Regarding #4952 (comment):
I have explained above why i consider #4952 to have priority. Frankly, if we cannot come to a consensus on an approach to addressing #214 given the admirable work @dch0ph has invested i see no point really in merging #4978. #4978 is a means to the end of improving our capabilities in map design, not an end on its own. If you would like changes to #4952 that depend on #4978 lets discuss those, work on consensus on that and then plan the releases accordingly. |
With #4952 merged i intend to prepare the release soon. I merged #4996 to be included in the release as well. My current perspective for after the release is to
Also we can think of follow-up changes to #4952 (like #4321, #4998, #1321, possibly a comprehensive solution for bus exclusive roads). |
5.8.0 is more than half a year ago so i think it would be good to think about a new release.
So far we have only few rendering relevant changes merged:
shop=hearing_aid
: Adding shop symbol: hearing_aids #4909barrier=jersey_barrier
: Render barrier=jersey_barrier #4923but we have two pending pull requests that are IMO ready to be merged and that would be good to include if we decide to accept them:
railway:preserved=yes
as preserved railway #4965Especially the first would be an important change (it addresses most of our second oldest open issue - #214 - and represents a major change in our paradigm of interpretation of tagging). And since both are making somewhat extensive modifications to the road layers it would be good to not to have these pending for too long to avoid larger merge conflicts. These are currently pending review by @pnorman (who had requested changes) and potentially further consensus building among the maintainers. Help/input from the other less active maintainers would be welcome.
I would leave #4978 for after the next release since we still need to discuss how exactly we want to proceed with that (when we move to make it mandatory to use the flex backend that would mean a new major version).
The text was updated successfully, but these errors were encountered: