Hi all, I have a question regarding modern best practices for go repositories. As we are building out services in go, we still have the opportunity now to refactor the service code pretty dynamically. So now is a good time to check and see if we're growing the repositories in a reasonable way. Our version management system is git (github).
There are two major routes I can see going down with regards to our organization's go code. 1. All internal code is in a single repository, and any time a developer wants to update an external dependency (ex: logrus or whatever), they are responsible for making sure the new version works on the rest of the code base by resolving function signature changes. This is closer to the mono-repo workflow. 2. All internal code resides in repositories which are split up into much smaller components. Each service service would be its own repository with its own build definitions, and the different "common libraries" would have their own repositories also. Each service lazily and independently updates their dependencies only when a dependency update is needed. This is closer to how the common Maven/SBT (java / scala) based artifact system works. Does anyone in the go community have some good suggestions or pitfalls regarding the above approaches? Or is there a different way that is suggested. Thank you, Charles Allen -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
