Skip to content
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

Open
imagico opened this issue Jun 13, 2024 · 7 comments
Open

Releasing v5.9.0 #4981

imagico opened this issue Jun 13, 2024 · 7 comments
Labels

Comments

@imagico
Copy link
Collaborator

imagico commented Jun 13, 2024

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:

but 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:

Especially 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).

@pnorman
Copy link
Collaborator

pnorman commented Jun 13, 2024

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.

@dch0ph
Copy link
Contributor

dch0ph commented Jun 22, 2024

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.

@imagico
Copy link
Collaborator Author

imagico commented Jun 22, 2024

#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.

@pnorman
Copy link
Collaborator

pnorman commented Jun 23, 2024

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!

@dch0ph
Copy link
Contributor

dch0ph commented Jun 23, 2024

I see no relation between #3012 and this release

The only connection in mind was that releases can be bundled with artifacts, such as the carto.xml. But if people can run an action more generally to generate a carto.xml for any commit point, that would be even more useful.

Also we would generally not wait for an issue to be resolved that doesn't at least have a PR!

Indeed, but knowing that a PR would be both welcome and feasible might inspire a contribution!

@imagico
Copy link
Collaborator Author

imagico commented Jun 23, 2024

The only connection in mind was that releases can be bundled with artifacts

For us releases so far are just tags in git - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/RELEASES.md

Indeed, but knowing that a PR would be both welcome and feasible might inspire a contribution!

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.

@imagico
Copy link
Collaborator Author

imagico commented Jul 12, 2024

Regarding #4952 (comment):

My strong preference would be to release 5.9.0, merge the flex PR, make the necessary column changes and normalization at import time, and then merge the style changes for being part of 6.0.0

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants