Closed mbfakourii closed 1 year ago
I will reformat the title to use the proper commit message syntax.
Patch coverage has no change and project coverage change: +0.27%
:tada:
Comparison is base (
aefc84e
) 39.33% compared to head (b6146ec
) 39.60%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@cool2apps Could you test this PR out, if it works for you?
@cool2apps Could you test this PR out, if it works for you?
I think it is ready for merge, it is no longer dependent on another library
Could you please change the PR title? It currently seems to describe the change, but it should describe the issue that is being fixed.
I changed it, I hope it's good, I didn't have a better idea for the title
The PR title must describe the issue, the solution of how it was fixed is an option addition. It's still not clear what this PR fixes. If it'S not "properly" displaying notifications, could we specify what that means? Or is it something else?
The PR title must describe the issue, the solution of how it was fixed is an option addition. It's still not clear what this PR fixes. If it'S not "properly" displaying notifications, could we specify what that means? Or is it something else?
I changed it, what do you think?
Again, this describes the change, not the issue that this PR fixes.
Again, this describes the change, not the issue that this PR fixes.
- Is this PR fixing a bug, then what does it fix?
- Is the PR adding a new or changing an existing feature and not fixing a bug, then what is that feature?
In this PR, we solved the problem of using the notification library overhead by removing it and replacing it with an interface. I think this PR solves a bug
If it was a bug we should be able to describe what's broken or not working, but that seems not possible. If it removes a overhead then maybe it's a performance improvement?
How about:
perf: Remove push notification library overhead by replacing it with a push notification interface
Just to confirm again, this PR does not require any changes in a developer's app code, right?
If it was a bug we should be able to describe what's broken or not working, but that seems not possible. If it removes a overhead then maybe it's a performance improvement?
How about:
perf: Remove push notification library overhead by replacing it with a push notification interface
Just to confirm again, this PR does not require any changes in a developer's app code, right?
Changes are required on the developer side. I think this is a breaking changes
but since ParsePush
is a new feature and this change is very small, I'm not sure there is a need for a MAJOR version increase.
We do not distinguish between "small" and "large" breaking changes. Any breaking change usually requires a major version increment, the exception being security fixes which are evaluated on a per-case basis.
but since ParsePush is a new feature
So then this is would be a feat
PR that contains a breaking change. A feat
is higher in priority than a perf
change, but we can add the performance implication in the changelog entry.
Merging a breaking change as non-breaking in flutter is especially bad due to the de-facto standard of using range operators for dependency versions. That means they will auto-update and potentially break apps. We need to be extra careful because of that.
We do not distinguish between "small" and "large" breaking changes. Any breaking change usually requires a major version increment, the exception being security fixes which are evaluated on a per-case basis.
but since
ParsePush
is a new featureSo then this is would be a
feat
PR that contains a breaking change. Afeat
is higher in priority than aperf
change, but we can add the performance implication in the changelog entry.Merging a breaking change as non-breaking in flutter is especially bad due to the de-facto standard of using range operators for dependency versions. That means they will auto-update and potentially break apps. We need to be extra careful because of that.
I got it, so it is a breaking change and feat
added in title
I think the PR title could be improved; with "user interface" you are probably referring to the programming interface, not a UI.
How about this change log entry:
BREAKING CHANGES
- The push notification library
flutter_local_notifications
is replaced with the new push notification interfaceParseNotification
(#949)Features
- Add new new push notification interface
ParseNotification
for managing push notifications (#949)
Feel free to add any info to the "breaking change" line that may help developers to cope with the braking change.
I think the PR title could be improved; with "user interface" you are probably referring to the programming interface, not a UI.
How about this change log entry:
BREAKING CHANGES
- The push notification library
flutter_local_notifications
is replaced with the new push notification interfaceParseNotification
(#949)Features
- Add new new push notification interface
ParseNotification
for managing push notifications (#949)Feel free to add any info to the "breaking change" line that may help developers to cope with the braking change.
I changed it, what do you think?
We would need a changelog entry as well
We would need a changelog entry as well
added
@mbfakourii I've edited the changelog; to better explain the format, when there's a breaking change, there is the BREAKING CHANGES
section that can be more verbose and explain what is breaking, how the developer can transition and what to be careful about. Then there is still the Features
section that has the shorter entry for the feature change. In other words, a PR always requires a base entry like Bug Fixes
or Feature
and if it's breaking it requires an additional entry in BREAKING CHANGES
.
Pull Request
Issue
Closes: #936
Approach
In the new method,
ParseNotification
should be given toParsePush
Tasks