3 ms·

> Yaml parsing - Used gopkg.in/yaml.v2 . What that means? I don't know. v2 could be one git hash today, and another tomorrow. I'm sure that you can use a fixed

by favadi 9y ago

> Yaml parsing - Used gopkg.in/yaml.v2 . What that means? I don't know. v2 could be one git hash today, and another tomorrow. I'm sure that you can use a fixed git hash if you want. > Slack SDK - Used nlopes/slack. dep ensure -add dumps me on to the latest release of Github. That was fine although I didn't realise that was what happened. The latest release is 12 commits behind master at the time of this writing Do you expect the author to tag a release every time he pushed to master? And you can use master branch if you want. > A CLI framework - Used urfave/cli. Same thing with dep ensure -add. Except I realised that the last release to Github was eons ago. August 2017 IIRC. The code I needed in particular had been released in October 2017 and since then had many commits to master. I just added a constraint to my Gopkg.toml file to lock the pulling to master. It is barely 6 months old! How often you expect the author to release new version?

nstart 9y ago
I'm not faulting anyone. Or any of the projects. I'm pointing out the fact that standardization of package version mangement from the package maintainer's side is something the Go community hasn't agreed on. All your replies describe workarounds. Use a git hash. Use the master branch. I did those. The point is that even if we haven't figured out package management within the software industry, we do have more mature practices than this. Do I expect the author to tag a release every time they push to master? Kind of actually. It depends on what's going into master. If it's typo fixes. Sure that can wait. If it's major bug fixes, that probably should be a release. If it's brand new features added, then yes! It has to be a release! Right now, people are treating each commit to master as a new release. I'm not angry or railing against anything. I'm an outsider who went through a lot of strange things in my first project in Go. I think this line from nlopes/slack README highlights the general package management methods: "v0.2.0 - Feb 10, 2018 Release adds a bunch of functionality and improvements, mainly to give people a recent version to vendor against." All I'm saying is that it'll be great if the community does figure this out and settles with a single agreed on practice. --- One last example: stretchr/testify is a library I considered using for testing. Their README encourages people to depend on the master branch. And even this PR acknowledges the issues that has caused: https://github.com/stretchr/testify/pull/274 https://github.com/stretchr/testify/pull/274 . I agree that there are workable workarounds. But that's exactly what they are. Workarounds.

by favadi 9y ago

nstart 9y ago

I'm not faulting anyone. Or any of the projects. I'm pointing out the fact that standardization of package version mangement from the package maintainer's side is something the Go community hasn't agreed on. All your replies describe workarounds. Use a git hash. Use the master branch. I did those. The point is that even if we haven't figured out package management within the software industry, we do have more mature practices than this. Do I expect the author to tag a release every time they push to master? Kind of actually. It depends on what's going into master. If it's typo fixes. Sure that can wait. If it's major bug fixes, that probably should be a release. If it's brand new features added, then yes! It has to be a release! Right now, people are treating each commit to master as a new release. I'm not angry or railing against anything. I'm an outsider who went through a lot of strange things in my first project in Go. I think this line from nlopes/slack README highlights the general package management methods: "v0.2.0 - Feb 10, 2018 Release adds a bunch of functionality and improvements, mainly to give people a recent version to vendor against." All I'm saying is that it'll be great if the community does figure this out and settles with a single agreed on practice. --- One last example: stretchr/testify is a library I considered using for testing. Their README encourages people to depend on the master branch. And even this PR acknowledges the issues that has caused: https://github.com/stretchr/testify/pull/274 https://github.com/stretchr/testify/pull/274 . I agree that there are workable workarounds. But that's exactly what they are. Workarounds.