Stale branches #3662
-
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 9 replies
-
yes
I figure this can be deleted. It was spawned by this issue: tangrams/tangram-es#2265 , or #2879:
was an attempted performance optimization / experiment. It is related to #3609 which is why I would like to keep it around a little longer until a conclusion is reached in that ticket. Also, the numbered branches are the branches for the releases. They are not feature branches and are not meant to be merged into master. They exist so that it is easy to cherry-pick certain fixes from master when master has moved on, so we can make bugfix-updates of old releases. I figure we could change how we organize this. But what is your suggestion exactly and how would it make it better? |
Beta Was this translation helpful? Give feedback.
-
|
I create a release branch only if i need one, i.e. master already moved on but a bifocal update on the last major update should be done. So, that wouldn't be part of releasing a new version, just the tagging of the commit is. |
Beta Was this translation helpful? Give feedback.
-
|
So, does this gitlab flow guideline suggest to delete old stable branches? |
Beta Was this translation helpful? Give feedback.
-
True. I thought about a section like "After the release" with a content like: "If need for minor release and other stuff already on master, then create release branch based off of the tagged commit and cherry-pick the fixes there."
It doesn't. Surprisingly, it's quite hard to find tips and suggestions about if and when to delete old release branches in any branch strategy. But I did find a StackExchange answer I do agree with: https://softwareengineering.stackexchange.com/a/361817 |
Beta Was this translation helpful? Give feedback.
-
|
You are invited to add this to the document if you think it makes sense. Also, I guess I have no case against deleting old release branches, so if you find it is more clear this way, go ahead and delete them |
Beta Was this translation helpful? Give feedback.
-
|
I added documentation in 92e4aef and deleted the stale release branches. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe even the in progress (but not actively being worked on) branches would be better as *annotated* tags, since then they can include an explanation of what they're for.
…On January 21, 2022 12:02:00 AM UTC, Tobias Zwick ***@***.***> wrote:
> satellite-down
yes
> weak-ref-to-tangram
I figure this can be deleted. It was spawned by this issue: tangrams/tangram-es#2265 , or #2879:
Updating map data from a background thread may result in a crash when at that point, the view has already been destroyed.
The changes on that branch would solve that theoretical cause for a crash but either I solved it in another way (i.e. map data is guaranteed to updated on a background thread) or this is only a theoretical concern (don't remember). In any case, I don't see a significant amount of tangram-releated crashes on google play console. (By the way, would you like to have access to it? You can see the crash reports, you can see statistics etc. this way, Mateusz has access too)
> fetch-by-bbox
was an attempted performance optimization / experiment. It is related to #3609 which is why I would like to keep it around a little longer until a conclusion is reached in that ticket.
--
Reply to this email directly or view it on GitHub:
#3662 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hmmm, not sure about that. It's difficult to get rid of unwanted tags again, see e.g. refined-github/refined-github#3421 (comment). I think it would be better to open draft PRs that reference the issue. Then it's also easy to delete the branch when the draft PR is not needed anymore. |
Beta Was this translation helpful? Give feedback.
-
@westnordost I think I don't need access there. It sounds like another time killer for me (diving into statistics and so on 😅) without much benefit. If you make the crash reports public in GitHub issues, all contributors including me can try to fix them. However, I can't help with most bugs anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Ok |
Beta Was this translation helpful? Give feedback.
-
|
@westnordost Are the
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, they are needed
On January 15, 2023 11:40:45 AM GMT+01:00, Flo Edelmann ***@***.***> wrote:
@westnordost Are the `create-vertices`, `create-vertices-experiment1` and `create-vertices-experiment2` branches still needed? Probably not, since StreetComplete is able to create new nodes since [v48.0](https://github.com/streetcomplete/StreetComplete/releases/tag/v48.0), right? Can we delete these stale branches then?
https://github.com/streetcomplete/StreetComplete/branches/all?query=create-vertices
--
Reply to this email directly or view it on GitHub:
#3662 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
Beta Was this translation helpful? Give feedback.
yes
I figure this can be deleted. It was spawned by this issue: tangrams/tangram-es#2265 , or #2879:
Updating map data from a background thread may result in a crash when at that point, the view has already been destroyed.
The changes on that branch would solve that theoretical cause for a crash at the cost of readability/higher complexity but either I solved it in another way (i.e. map data is guaranteed to updated on a background thread) or this is only a theoretical concern (don't remember). In any case, I don't see a significant amount of tangram-releated crashes on google play console. (By the way, would you like to have access to it? You can se…