Provides tags for releases

[nlamirault]

Do you think it is possible to manage pq with tags ? and using semver ?

[asdine]

It would be really useful, Dep, Glide and other dependency managers are already semver compatible.

[maddyblue]

I agree this should happen. Someone, probably one of us maintainers, but anyone else could too, needs to come up with a concrete plan addressing:

• which version do we start with
• when do we update versions (on each commit? there aren't that many...)
• will we still do all our work on master or will there be a branch
• should/will this use git tags
• will this break any current users
• maybe other stuff I don't realize yet

[asdine]

will we still do all our work on master or will there be a branch

will this break any current users

I don't think you should change anything regarding your workflow on master, a lot of people don't use dependency managers and some do but might have configured them to use the master branch instead of a specific commit sha. Semver should just be a bonus.

should/will this use git tags

Basically, for this to work all you gotta do is to create a release here https://github.com/lib/pq/releases/new with a semver compatible name. This will create a git tag that will be parsed by Dep, Glide and others.

when do we update versions

The semver spec does a good job describing when to change the version name and how

[djui]

Any update on this?

a lot of people don't use dependency managers

(I assume your context here is to not uses branches other than master. But just to clarify my argument:) this has changed a lot recently with the advent of Go Dep. And what keeps most people from using it confidently and conveniently is to have popular dependency authors start using semver.

and some do but might have configured them to use the master branch instead of a specific commit sha.

This only works with Go Dep for non-transient dependencies. As soon as you have e.g. pq as a main as well as transient dependency, and not both are written as branch=master (which can easily happen as you do not always have influence over the transient dependencies) Dep will refuse to satisfy the constraint.

Additionally, it is just not good style. Take the example of https://github.com/mattes/migrate Taking just branch=master would have broken systems when the author changed implementation from v1 to v3.

I agree this should happen.

I believe you and asdine agree with starting to use more tags/releases is desired, I just wanted to express my arguments for why I see it more than a convenience.

My suggestion:

• which version do we start with
  Take any random latest commit and tag it v1. Since 8081c7d nothing API changing was introduced and that was roughly 3 months ago. So I could consider the library currently stable, so no v0 required anymore. I would suggest any commit equal or later than this one.

• when do we update versions (on each commit? there aren't that many...)
  Maybe the first decision making factor would be that this could be done on request, usually when contributors propose PRs they will be API changing and thus could qualify to trigger the "new minor or bug fix version" process. If they don't explicit request it, deferring it. The second one could be: every 2-3 months, a maintainer cuts a new release (if there are any changes) similar to how Go versions progress (every 6 months a new version).

• will we still do all our work on master or will there be a branch
  I recommend this. Dependency users are usually aware that master is (still) no guarantee for always bug free, even compiling state.

• should/will this use git tags
  Yes. Github Releases implicitly create Git tags iirc.

• will this break any current users
  I can't see that happening.

• maybe other stuff I don't realize yet
  Maybe cutting a release could be streamlined and maybe consistent with a /release.sh script that helps the maintainers to: update the readme, changelog, create tag, create release, announce on go-nuts, etc.

[flibustenet]

With the new vgo proposal, it's time to tag ?
https://research.swtch.com/vgo

[maddyblue]

Yes, I think we should start using whatever vgo wants.

[malexdev]

Any update on this? Seems that the decision was made to start tagging releases, but we still don’t have a tagged release (other than the go1.0 cutoff).

[AlekSi]

Older issue #590 had some 👍.

[rumyantseva]

As Go Modules are going to be presented as a part of Go 1.11, that would be really nice to add tags to this repo. The simplest semantic versioning will be enough (e.g. smth like git tag -a v0.1.0 -m "version that supports go modules" && git push origin v0.1.0).

Could somebody from the code owners participate? (ping @mjibson)
Thank you in advance.

[maddyblue]

Yeah I think I should just tag this with v1.0.0. Anyone opposed to choosing that version number? lib/pq is old enough I think we can just start at 1.0.

[malexdev]

I agree, v1.0.0 is good. We have been using this in production for months, we certainly consider it 1.0.0.

…

Sent from my iPhone

On Aug 21, 2018, at 12:59 PM, Matt Jibson ***@***.***> wrote: Yeah I think I should just tag this with v1.0.0. Anyone opposed to choosing that version number? lib/pq is old enough I think we can just start at 1.0. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[flibustenet]

I believe we should also add a go.mod file just with module github.com/lib/pq

[maddyblue]

Could someone review #778? Reading the go mod docs I'm not fully convinced why we need a go.mod file. Can someone explain it?

[flibustenet]

lib/pq doesn't use any dependency. Then it will not change a lot to have a go.mod file or not.
But i think with an empty go.mod file it's more explicit for a reader or a tools. Also for history (if one time there is a dependency). It also show that it's module aware.

[maddyblue]

Great. That was my understanding. I wanted to make sure I didn't miss anything. Would you mind adding a review to that PR?

[thepudds]

My quick two cents:

At this point, it is not required because the whole module system still opt in, but there is still value in running go mod init and checking in the resulting go.mod file. It helps the ecosystem see more clearly that you've opted-in, it helps your consumers including if you are on v2+, and a go.mod might be required in the future. There are also some more subtle things where the module directive in a go.mod is serving as a definitive declaration of sorts for the identity of your code (which is part of what might then translate to import comments on package statements being deprecated in the future as no long needed), and it helps with (optionally) working outside of GOPATH...

[maddyblue]

https://github.com/lib/pq/releases/tag/v1.0.0

[djui]

@mjibson Thanks guys!

[nlamirault]

Thanks !

[asdine]

Thanks !

[rumyantseva]

Thank you!