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

Release 1.2.0 #66

Closed
wants to merge 1 commit into from
Closed

Release 1.2.0 #66

wants to merge 1 commit into from

Conversation

pankajastro
Copy link
Contributor

No description provided.

@@ -1,5 +1,22 @@
# Changelog

## 1.2.0 (2023-10-31)

### Breaking changes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qq on whether these breaking changes call for a major semver release? or if it's possible to avoid having breaking changes?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My $0.02 is they are extremely minor breakages that will impact almost no users. I hesitate to even call attention to them; I am just very thorough.

Also, this is outdated and no longer true:

For users using the sync hook directly to call either get_sync_status or call_and_restart, they will experience breakage if they are using reschedule_time=

We resolved this by adding a (deprecated) kwarg to each of those methods.


The changes in #58 would certainly constitute a major version bump, though, if that gets merged before the release. (Working on resolving that right now, sorry for delays.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify:

  • I cannot imagine any users setting reschedule_time=0 and also relying on the default behavior of not actually waiting 0 seconds.
  • I cannot imagine any users relying on the return value of prep_connector, which was always True, unless they misunderstood it to sometimes return False and used its truthiness to do something.
  • Same as above for check_connector, which originally returned True always.

These really do seem to constitute minor changes, in my eyes. These are changes that are relatively deep in the API, with return values changing that had no real use anyway. The only high-level-API-facing change was to make a 0 default into a None default so that the 0 could mean sleep(0). Even that is not especially consequential of a change in the very rare event a user would be impacted; it would just mean that manual resyncs get rescheduled faster than normal, and it could even have been what the user originally intended if they were explicitly setting it!

@pankajastro
Copy link
Contributor Author

closing in favour of #67

@pankajastro pankajastro closed this Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants