-
Notifications
You must be signed in to change notification settings - Fork 60
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
Docs update #37
Comments
Sounds good. I've added a draft PR where we build out the README a little better. |
Awesome, also how about renaming the trait to something like So far the trait name is the same as the To keep the current implementations working we could create a trait with the right name and make that trait use the current such that users can use them interchangeably until when we finally depricate the prevous |
I'm less concerned about the names being the same than I am about introducing a breaking change. A decent IDE will make it pretty clear when you're trying to use the wrong thing. I'm open to being convinced but I don't see how the two having the same name would have any negative consequences other than maybe having to alias one of them if you're using both in the same class and I can't figure out why anyone would ever want to do that. So if we ever get to the point where a total rewrite is called for or some other good reason comes up to release a v2.0 we will definitely rename one or the other. But my thinking at the moment is that it's not a good enough reason to bump major versions right now. |
So i dont know what you guys think but i was suggesting that we promote more the use of the
config
file or thetrait
.I have seen that so far we are requiring like 9 more entries on the this package on the .env file and if we think of something new it means thats one more line.
The whole database uses only 5-6 lines on the
.env
and a whole load of config data.I dont know but what do you think?
The text was updated successfully, but these errors were encountered: