Branch cleanup

[fredgalvao]

Expected Behaviour

Clean and consise branch timeline/tree.

Actual Behaviour

We have a ton of branches that outlived their yet-to-be-seen importance.

Reproduce Scenario (including but not limited to)

Steps to Reproduce

Click here

Shall we do a cleanup on those branches?, that:

have already been merged

• raghav/toast_Capable
• raghav/background_notifications
  • This has been merged but there is one leftover commit: d620969
• raghav/doclaunch

have no diff from master (most of them have diff to master, as they're outdated)

• blackberry
• icons
• issue230 Refactor key extraction into configuration file #230
• issue299 1.4.x not showing notification on Android #299
• issue79 Subscribe to Topics... #79
• v1.7.x
• issue683 Support Android N inline reply actions #683
• v1.9.x

have a diff from master but that diff has already been cherry-picked to master

• issue144 Crash with Android at startup #144

who knows

• cocoapod_support
• v1.5.x-pod
  • This superseeds/contains the cocoapod_support branch.
• v1.6.x V1.6.x #671
  • This seems to be someone trying to merge a branch into master that had already been merged (the PR was closed, but the commits are unlinked)
• amazon
  • This branch has some nice ideas of separating concepts and abstracting our code that would allow people (like myself) to adapt the plugin easily to work with third-party providers, like Pushy.me or Amazon. IMO this should be considered and not deleted right away. [WIP] Amazon Device Message Support #822
• background
  • I didn't dig deep, but this seems like something that has been superseeded by a more recent version.
• es6
  • I want this to be true (I'd prefer Typescript, but hey, ES6 is cool too).
• browser
  • Hasn't this been done on master too?
• v2.0.x
  • Is superseeded by the new v2.0.x-rebase
• windows classisnetrr #1087
  • Code is superseeded by what's already on master

[macdonst]

@fredgalvao all of the branches I've put checkmarks beside can be cleaned up. I want to leave the following around:

• v1.9.x - may end up becoming a legacy support branch for folks not moving to FCM.
• cocoapod_support - Holly was looking at turning this plugin into a CocoaPod so this will be a reminder of where she left off.
• amazon & blackberry - legacy but still interesting
• es6 - yup, plan on doing this once v2.0.x is out.
• v2.0.x - once @jcesarmobile and I straighten out the rebase I'm going to push v2.0.x-rebase to v2.0.x and delete v2.0.x-rebase.

Feel free to start cleaning and thanks for supporting this project!

[fredgalvao]

Should I leave v1.5.x-pod alive and delete cocoapod-support instead? The former works on top of the later, so if we want to preserve all work done on the topic, v1.5.x-pod is the one to preserve imo.

[macdonst]

@fredgalvao nah, I think the work will need to be restarted so just having Holly's commit in cocoapod-support will be enough of a hint to get her going.

[fredgalvao]

I forgot the windows (#1087) on the way. Seems outdated to me. Removable?

[fredgalvao]

Yep, just verified and the code on that windows branch is already on master. I'm adding it to the OP for reference and deleting it.

[fredgalvao]

Seems good enough for now! (now to create a few new branches/issues for crazy ideas I have for the api...)

[macdonst]

@fredgalvao at some point the two of us and @jcesarmobile should get together for a roadmap planning session. Rough schedule is:

• FCM support
• ES2015 API changes
• W3C Push API implementation (tricky without service worker support).

[fredgalvao]

@macdonst I'd love to have a chance at sharing my opinion on some of those topics.

[lock]

This thread has been automatically locked.