-
Notifications
You must be signed in to change notification settings - Fork 101
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
Go Modules Support #28
Comments
@wlynch This is my first experience with Go modules, let me know if you have any thoughts/comments or alternatives. |
See https://golang.org/doc/go1.13#modules for more details. Also pulls in some auto-formatting changes. Fixes bradleyfalzon#28
See https://golang.org/doc/go1.13#modules for more details. Also pulls in some auto-formatting changes. Fixes bradleyfalzon#28
This is also my first hands-on experience with go modules! Played around with it a bit and created #29 . Modules will not actually make breaking changes any better for #27. The main benefit they provide is to pin the dependencies of ghinstallation so that if one of our dependencies makes a breaking change we (and our dependents) will be resilient to it. As long as we continue to follow vX.X.X semver, ghinstallation should be compatible for others to use with modules within their own projects. |
Give me a few hours and I’ll try and get a look!
Thank you, you’re a champ!
On Thu, 10 Oct 2019 at 9:15 am, Billy Lynch ***@***.***> wrote:
This is also my first hands-on experience with go modules! Played around
with it a bit and created #29
<#29> .
Modules will not actually make breaking changes any better for #27
<#27>. The main
benefit they provide is to pin the dependencies of ghinstallation so that
if one of our dependencies makes a breaking change we (and our dependents)
will be resilient to it.
As long as we continue to follow vX.X.X semver, ghinstallation should be
compatible for others to use with modules within their own projects.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#28?email_source=notifications&email_token=AAN74UON4HYASLJR4PUP67LQNZNIBA5CNFSM4I3MB7UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAZV37I#issuecomment-540237309>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN74UK5EOXWEQFNZN3LQD3QNZNIBANCNFSM4I3MB7UA>
.
--
Bradley Falzon
[email protected]
|
See https://golang.org/doc/go1.13#modules for more details. Also pulls in some auto-formatting changes. Fixes bradleyfalzon#28
See https://golang.org/doc/go1.13#modules for more details. Fixes bradleyfalzon#28
As discussed in #27, and other breaking changes discussions such as #21, we should maintain our own tagging, as well as go module support for our dependencies.
Currently, tags do exist up to
v0.1.2
, however, since then there have been breaking changes in #21 and another proposed in #27.Because this library is still, essentially v0, I think it may be OK to push
v0.1.3
pointing to latest commit even though it would then tag a breaking change. Once #27 is resolved, and if there's no immediate list of breaking changes,v1.0.0
could be released.Along with
v0.1.3
tag, we can add Go modules commit, as I see no reason not to add that.The text was updated successfully, but these errors were encountered: