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

cleaning up APIs #387

Closed
kazu-yamamoto opened this Issue Jun 17, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@kazu-yamamoto
Contributor

kazu-yamamoto commented Jun 17, 2015

Network.Wai.Handler.Warp exporting low level APIs and internal APIs. But we have Network.Wai.Handler.Warp.Internal, too. I would like to move them to Network.Wai.Handler.Warp.Internal so that Network.Wai.Handler.Warp gets simpler.

@snoyberg What do you think?

@snoyberg

This comment has been minimized.

Member

snoyberg commented Jun 17, 2015

I'd like to have a deprecation cycle for whatever we're going to move, but honestly, I'm not too terribly concerned about it. Yes, doing something like this is a good idea, thank you for raising it.

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jun 17, 2015

OK. I will do two things:

  1. Preparing a new rich Network.Wai.Handler.Warp.Internal
  2. Making the low level ones and the internal ones in Network.Wai.Handler.Warp.Internal deprecated

One more question: Network.Wai.Handler.Warp.Internal has deprecated APIs. May I remove them? Or is it too early?

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jun 17, 2015

And please decide the next version number of Warp? I should write "Since: 3.X.Y" for new ones. I guess it should be 3.1.0.

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jun 18, 2015

Please merge #388. This does 1). But this does not do 2) because there is not a simple way to make reexported ones deprecated. The deprecated pragma must be used with declaration. To implement 2) for functions, we need a lot of boilerplates which I don't think pay. For types, it seems to me that 2) is impossible.

In the patch, the new document of Network.Wai.Handler.Warp just says "The following APIs will move to Network.Wai.Handler.Warp.Internal" in the Internal section.

@snoyberg Do you think that this is good enough? Or perhaps, we could remove the Internal section completely since there is just one user: WarpTLS.

@snoyberg

This comment has been minimized.

Member

snoyberg commented Jun 18, 2015

I think of we announce the plan to remove functions, wait a week or two, and then do it, we can do basically whatever we want.

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jun 19, 2015

@snoyberg I will do the following:

  • Setting the version to 3.1.0
  • Removing the settingsXXX functions on github
  • Leaving the internal ones on the top module and writing a document that these will be removed in 3.2.0
  • Announcing this cleanup by yesodweb blog

Make sense?

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jun 19, 2015

All but blog are done on the master branch.

@snoyberg

This comment has been minimized.

Member

snoyberg commented Jun 19, 2015

Yes sounds good

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jun 19, 2015

OK. I will write a blog article next week.

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