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

Plugins renaming #480

Closed
thibaultcha opened this issue Aug 17, 2015 · 9 comments
Closed

Plugins renaming #480

thibaultcha opened this issue Aug 17, 2015 · 9 comments
Assignees
Labels
idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports.
Milestone

Comments

@thibaultcha
Copy link
Member

For consistency and usability plugins will be renamed. Since 0.5.0 includes a breaking change in the database schema (#443), it will also include a migration script. This script is a good opportunity to also rename plugins (since it would not be backwards compatible).

Naming conventions:

  • No capitals
  • Must be readable (requestsizelimiting -> request-size-limiting)
  • Use dashes only, no underscores
  • No spaces

Here are some suggestions, please comment in this thread and this issue will be updated with approved suggestions:

Old name New name
ssl ssl
keyauth key-auth
basicauth basic-auth
oauth2 oauth2
ratelimiting rate-limiting
tcplog tcp-log
udplog udp-log
filelog file-log
httplog http-log
cors cors
request_transformer request-transformer
response_transformer response-tranformer
requestsizelimiting request-size-limiting
ip_restriction ip-restriction
mashape-analytics mashape-analytics
@thibaultcha thibaultcha added the idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports. label Aug 17, 2015
@thibaultcha thibaultcha added this to the 0.5.0 milestone Aug 17, 2015
@ahmadnassri
Copy link
Contributor

should perhaps prefix with something to indicate "official" status

e.g. mashape-http-log, or official-http-log, kong-http-log etc ...

@thibaultcha
Copy link
Member Author

That makes it painful to configure though (especially since all of them are currently official). I would rather wait until we have our own plugins platform and a web UI certifying them as official.

@ahmadnassri
Copy link
Contributor

That makes it painful to configure though

yep

I would rather wait until we have our own plugins platform and a web UI certifying them as official.

I think the community is already itching for plugin separation, and some already are forking and adding their own functionality to plugins, some maybe existing plugins too (under the same name)

if we're taking the opportunity to do a single renaming now, then might as well.

also, we can also follow a "namespace" approach, much like docker:

mashape/http-log would be the same as http-log ... thus the default namespace is mashape

@sonicaghi
Copy link
Member

official/not official: i see this coming but not soon. we'll need to have a "dockerhub/atmopshere" platform first.

@thibaultcha thibaultcha self-assigned this Aug 21, 2015
@thibaultcha
Copy link
Member Author

Renaming basicauth and keyauth will change the route:

/plugins/basicauth/schema

to:

/plugins/basic-auth/schema

And to keep things consistant, I would also change the routes:

/consumers/:consumer/basicauth
/consumers/:consumer/basicauth/:id
/consumers/:consumer/keyauth
/consumers/:consumer/keyauth/:id

to:

/consumers/:consumer/basic-auth
/consumers/:consumer/basic-auth/:id
/consumers/:consumer/key-auth
/consumers/:consumer/key-auth/:id

Now that would be kind of a breaking change. So should we:

  • Rename the plugins (and the schema route) and not change those routes
  • Rename the plugins and change the routes for consistency
  • Not rename those plugins (keep basicauth and keyauth) at the cost of making it less consistent with other plugins names

@ahmadnassri
Copy link
Contributor

option 4:

  • have aliases for this version family 0.x and remove them at the next version family bump 1.x (a.k.a backward compatibility, per version family)

@thibaultcha
Copy link
Member Author

I didn't want to consider this option since we are still in 0.x and don't already want to start with maintaining backwards compatibility all across the project. For ex the migration script finally takes care of migrating some data for us to remove the backwards compatibility support in the code. Same for plugins renaming, we really want to move forwards.

Now I can do it but the spirit of 0.5.0 was to finally move forward in a lot of stuff we postponed.

PS: 0.5.0 should also proceed to the renaming of the configuration properties and db values (target_url -> upstream_url)

This was referenced Aug 26, 2015
@thibaultcha
Copy link
Member Author

#512 supports both routes and a deprecation notice in CHANGELOG and UPDATE.

@ahmadnassri
Copy link
Contributor

your argument is valid, I'm just listing additional option :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports.
Projects
None yet
Development

No branches or pull requests

3 participants