Documenting development process #81

New Issue

asdf · 2019-11-07T11:55:29Z

asdf commented

2019-11-07 11:55:29 +00:00

This is an extension of PR #78 , but I thought it might be better to discuss this and get some feedback before raising a PR.

Branch support-different-go-versions has been updated to add documentation for #78, but it became general advice on how to develop for Bombadillo.

Furthermore, the makefile has a new target make test that will build bombadillo with a fixed version of Go. The idea being that tests can be performed uniformly and we have an agreed version to test against.

In the future, similar changes to the makefile could handle linting, helping with #65.

All of these changes would see a more uniform approach to the development process. This is not a requirement, but might be nice to have.

Let me know what you think!

This is an extension of PR #78 , but I thought it might be better to discuss this and get some feedback before raising a PR. Branch `support-different-go-versions` has been updated to add documentation for #78, but it became general advice on how to develop for Bombadillo. Furthermore, the makefile has a new target `make test` that will build bombadillo with a fixed version of Go. The idea being that tests can be performed uniformly and we have an agreed version to test against. In the future, similar changes to the makefile could handle linting, helping with #65. All of these changes would see a more uniform approach to the development process. This is not a requirement, but might be nice to have. Let me know what you think!

asdf added the

labels 2019-11-07 11:55:29 +00:00

sloum commented

2019-11-07 14:40:38 +00:00

I definitely want development to be readable, stable, and functional. So this sounds good. I agree with using 1.11 as the test target (given it is the lowest version we are officially supporting). I think more details on how to contribute ultimately help the project. I do not think I am wanting or hoping for a large number of contributors, but it would be nice eventually (if this grows) to have a few stable contributors and the odd PR from a random contributor and having clear instructions on how to submit code is a good call.