Remove run_on_change deprecation #298

Closed
colszowka opened this Issue Jul 1, 2012 · 5 comments

Comments

Projects
None yet
3 participants
@colszowka

I think the run_on_change deprecation introduced in 3db6ee1 is too rude: It forces guard gem authors to either break backwards compatibility or force up-to-date users to read through (when in doubt multiple incarnations) of a 7-line deprecation warning.

I think the main motivation of the change was to make guard gem authors aware of the fact there's also run_on_additions and run_on_modifications to take care of, but in most situations guard gems are actually only interested in run_on_changes, for which run_on_change is an adequate alias in my opinion, and does not break the existing API in a manner that it needs to be extinguished ASAP. Also, this obviously hits more guard gem users than authors, so I think that the deprecation warning is a misplaced means of communication here.

In my opinion the docs for guard authors should point out to prefer run_on_changes over the singular version, but for the two reasons mentioned above I think the other one should be just as fine.

@colszowka

This comment has been minimized.

Show comment
Hide comment
@colszowka

colszowka Jul 1, 2012

Also, in plenty of places the API docs still refer to run_on_change :)

Also, in plenty of places the API docs still refer to run_on_change :)

@netzpirat

This comment has been minimized.

Show comment
Hide comment
@netzpirat

netzpirat Jul 2, 2012

Contributor

Yep, I'm with Chris. Active maintainers have already changed their Guard plugins, all the others will probably never. So why bother Guard users with this deprecation warning?

I'm for either removing it completely or add a new option like --show-deprecations that plugin authors can explicit enable to check if their Guard plugin uses any deprecated API.

What do you think @guard/core-team?

Contributor

netzpirat commented Jul 2, 2012

Yep, I'm with Chris. Active maintainers have already changed their Guard plugins, all the others will probably never. So why bother Guard users with this deprecation warning?

I'm for either removing it completely or add a new option like --show-deprecations that plugin authors can explicit enable to check if their Guard plugin uses any deprecated API.

What do you think @guard/core-team?

@thibaudgg

This comment has been minimized.

Show comment
Hide comment
@thibaudgg

thibaudgg Jul 2, 2012

Member

I agree, +1 for --show-deprecations

Member

thibaudgg commented Jul 2, 2012

I agree, +1 for --show-deprecations

@netzpirat netzpirat closed this in 23777b7 Jul 2, 2012

@netzpirat

This comment has been minimized.

Show comment
Hide comment
@netzpirat

netzpirat Jul 2, 2012

Contributor

Thanks @colszowka for speaking wisely. Guard 1.2.2 is out in the wild that contains the little patch to give back freedom to the many Guard users out there.

Contributor

netzpirat commented Jul 2, 2012

Thanks @colszowka for speaking wisely. Guard 1.2.2 is out in the wild that contains the little patch to give back freedom to the many Guard users out there.

@colszowka

This comment has been minimized.

Show comment
Hide comment
@colszowka

colszowka Jul 2, 2012

Cool guys, thanks for the quick update!

Cool guys, thanks for the quick update!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment