-
Notifications
You must be signed in to change notification settings - Fork 826
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
Release v2.45.1/v3.0.0 #2483
Comments
Not a good idea IMO - if there is a fix needed for a serious problem then it should be done but this has nothing to do with the rest. |
If we need to do a bugfix release that should be done immediately, and doesn't depend on other stuff merged to master. Because we've merged stuff to master, we'd do the bugfix off of a branch anyways, because we can't have something like #2279 in a patch release. I'd want to merge #2473 at the start of a release cycle, not the end. |
Looks like the branch release is complicated. I've made a branch (name is different than tag name to avoid git confusion): https://github.com/gravitystorm/openstreetmap-carto/tree/v2.45.1-branch but then new links in changelog do not work and I don't know how to push tags to be seen in GitHub. Could somebody more fluent in git/GitHub make it releasable (or, even better, make a bugfix release)? |
Partially fixed - my bad, I just pushed the tags to my fork instead of this repo. Now we have the v2.45.1 tag and link to changes between v2.45.0 and v2.45.1 works, but link to unreleased shows also #2482 (as unreleased). Is it worth changing at all? |
I realized that "Unreleased" section is broken anyway - it works properly only in master branch of git. Any previous release changelog link will show every code used in later releases as "unreleased". We may rethink it later (I suggest dropping this link and removing mention of it in RELEASE.md), but for now it won't be worse than before. New release deployment ticket is open now. |
Thanks @kocio-pl ! |
It looks like we should make a bugfix release soon to repair icon problems, but we're also almost ready to release v3.0.0, which would just break software requirements. It was proposed that we release both versions at the same time and leave the decision which one should be deployed to the server admins, which sounds reasonable for me.
Proposed solutions:
Probably the only other PR I could consider if it's ready in a day or two is #2480.
What do you think? How much time is needed to merge #2473 and #2480?
The text was updated successfully, but these errors were encountered: