Open RavinderReddyF5 opened 4 years ago
RavinderReddyF5
commented
4 years ago 
@fcgravalos agreed this was exception as customer wanted the fix, but now connivence them to use pool attachment resource, hence forth will have commits in dev branch and PR after that.
RavinderReddyF5
commented
4 years ago 
@scshitole I understand your rush, but you opened the provider to an opensource community so there's no single customer. This is not your customer's product, this is an opensource project. If a customer require specific customizations that are not aligned with the project, I'd recommend you to fork the repo.
RavinderReddyF5
commented
4 years ago 
Thank you @scshitole!
Just bear in mind that specific customer/user need cannot dictate direct changes like that to a community driven project, changes here impact a wide range of users and should be properly reviewed and tested.
Any one user that wants something changed can file a change request (issue) and/or submit a PR, if that change is accepted - great, if not - he may always fork the project and make any changes he deems necessary for his specific needs.
This is a common practice when working with any OSS tool.
@scshitole That's not the proper way to provide a stable release. It doesn't make any sense and looks very unprofessional. As an example:
https://github.com/terraform-providers/terraform-provider-bigip/commit/d8db2599dc8ad437026a71d65ab6adaa00ef430a
I'd encourage you to create feature branches that you merge into an development/integration branch when a PR is approved. I'd be desirable too to freeze at some point that branch and create release branches (v0.0.1, 2,3 ...) that will only contain bug fixes for those versions.