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

What is your version support policy? #123

Open
iyefrat opened this issue Sep 9, 2020 · 3 comments
Open

What is your version support policy? #123

iyefrat opened this issue Sep 9, 2020 · 3 comments

Comments

@iyefrat
Copy link
Contributor

iyefrat commented Sep 9, 2020

MPD version 0.21 has introduced filters and groups as a way to have more finely tuned metadata requests. I would like to send a MR that implements support the new commands, but it would require bumping the mpd version requirement significantly, or at least introducing listOld type commands for the older versions. What do you think is the best way to do this?

@psibi
Copy link
Collaborator

psibi commented Sep 9, 2020

I think @sol or @joachifm can answer that better. I'm mostly involved in maintaining this package for xmonad-extras depenendencies!

Can something like this be done: Introduce the functionality in a separate function and do a version check at runtime: https://hackage.haskell.org/package/libmpd-0.9.1.0/docs/Network-MPD-Core.html#v:getVersion and use the appropriate functions ?

@joachifm
Copy link
Contributor

If the changes do not affect existing users (adding new commands or constructors), I think it's fine to add them even if they would fail if a user were to run them against an unsupported MPD instance (provided the version requirement was documented). Changes that break existing users are generally unacceptable at this point without a major version bump (maybe even forking the name, as in "libmpd2" or something like that).

IMO, doers should be deciders so I'm happy to leave this to people interested in doing the work, with the proviso that existing users are not broken willy nilly.

@iyefrat
Copy link
Contributor Author

iyefrat commented Sep 13, 2020

I think I actually might be able to implement this in a backwards compatible way by changing Query to a sum type that corresponds to both the old and new options, and having the construction operators default to the old syntax if the logic is simple enough. This both shouldn't break for existing users of the library and lets them support older MPD versions if they want to.

If this doesn't work, I can either create a separate Filter type and create a bunch of variants such as listFilter, and add a dummy typeclass so that =? can be used for both versions. I don't love this from an aesthetic perspective, but it kind of sounds like having this as a breaking change would be unacceptable on your end even with bumping to version 0.10? I don't really want to create a libmpd2 and have two versions of the library. Also after some thought I feel like MPD 0.21 is just barely old enough to be the oldest version supported, and the version on debian buster is 0.21.5, which has some bugs related to this that were only fixed in 0.21.6.

At any rate, I'll try sending a MR implementing this sometime in the next month or so, depending on free time etc.

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

No branches or pull requests

3 participants