Please tag releases

[onlyjob]

Formal releases are useful to define dependency relationships between software components; 3rd party developers would be able to bundle somewhat "stable" version of your software instead of just top of "master".
Also it is helpful to downstream maintainers for numerous reasons.

Please consider tagging. Thanks.

[miekg]

master should be stable enough, also I'm not really looking forward into writing changelogs 'n stuff. So I can tag, but I am not sure what that adds.

[onlyjob]

Changelogs are really optional but tags are useful to define package dependencies like (>= 1.1). Always packaging top of master can be problematic...

[andrewtj]

Tags are a detraction unless @miekg wants to do formal versioning such that >= 1.1 is meaningful in some way. Pinning to a commit is a better option without meaningful versions.

[onlyjob]

@andrewtj, you can't pin commit in package dependencies. Version is different because it is incremental. Look at all important projects in Golang ecosystem -- Docker, Etcd (and many others) -- they use traditional versioning and for a good reason... It is OK it there is only one meaningful version. When new feature (or API breakage) introduced then a new tag can be made but one does not have to tag every commit. Another reason for tags/releases is to mark somewhat stable (better tested) versions comparing to random commit from master...

[andrewtj]

@andrewtj, you can't pin commit in package dependencies.

go get can't nominate a git tag any more than it can nominate a git commit. If you're using something else that understands tags it probably understands commits. That's incidental though.

Version is different because it is incremental. Look at all important projects in Golang ecosystem -- Docker, Etcd (and many others) -- they use traditional versioning and for a good reason... It is OK it there is only one meaningful version. When new feature (or API breakage) introduced then a new tag can be made but one does not have to tag every commit. Another reason for tags/releases is to mark somewhat stable (better tested) versions comparing to random commit from master...

That's more along the lines of what I tersely tried and failed to get at. (It's Sunday, give me a pass.)

You're asking for more than just running git-tag. As far as I understand, @miekg shepherds the project along keeping master as sane as possible at the bleeding edge of standards, avoiding breaking changes wherever reasonable, and with support for the last two versions of Go. That's not a small commitment.

Going beyond that to what you're asking for will take further commitment and that'll also fall on one person. There's benefits, but for my $0.02, I don't know that it'd be a win for the project at it stands.

[onlyjob]

I am asking to follow software versioning practice that was established in the industry for somewhat 20 years.

Only developers use go get. Everybody else install packages provided by GNU/Linux distributions. I've already seen situations where software A bundles one version of library C and software B uses another revision of library C. Then software D built on top of A and B indirectly uses two different versions of C at the same time and things break...
When we build packages we need to have common reusable libraries, preferably versioned so dependencies can be easily defined.

[andrewtj]

Okay, I failed again. One last shot from another angle: @onlyjob, if a new version were tagged today, what would that mean? Things I wonder:

• How was new functionality vetted?
• How were old features deprecated?
• What is the API stability story?
• What did the test cycle look like?
• What versions of Go and on what platforms does it support?
• How was that decided on?
• How long will it be supported for? And for security issues?
• How did all the above happen?
• When will the next release occur?

Again, I'm not disputing the value of formal versioning. I'm just saying I don't know if it'd be a clear win from what you've offered so far. You've said you need versions, okay, quantify what that entails. Then it'll be easier to judge the amount of work and who'll be prepared to do it.

[onlyjob]

All those are up to whoever prepares a release. As for "supported" (if you can even define what it means) I suppose it will be no different from current situation (i.e. only latest release is "supported", whatever it means). I'm not going into details regarding how and when to increment release number. Usually it depends on accumulated changes.

[miekg]

[ Quoting notifications@github.com in "Re: [dns] Please tag releases (#280..." ]

As far as I understand,
@miekg shepherds the project along keeping master as sane as possible at the
bleeding edge of standards, avoiding breaking changes wherever reasonable, and
with support for the last two versions of Go. That's not a small commitment.

Yes, this is the "contract" for Go dns master branch.

Versioning will help you, but will take up more time on my side. Time I
don't have.

Also in the 5+ years Go DNS has existed, none of the users of this lib have
asked for versioning. Mostly (I think) because the master branch is really
stable and people may also vendor the deps in their code.

Wondering about that last thing; is this something you need in your code, or
it this a (distribution) packaging thing? Because this would mean that I feel
forced to have multiple active versions to avoid stuff like this:
#276 Again something that takes up a lot
of time and energy.

/Miek

Miek Gieben

[onlyjob]

I know package maintainers rarely trouble themselves to ask their upstreams for versioning...

It is a packaging thing so versioning is suppose to be helpful to more people than just me... You do not need to worry about multiple versions as long as you support latest release.

"Vendoring" is a bad thing but versioning helps to avoid bundled code copies.

You might find it interesting to read Debian UpstreamGuide...

We have a ticket to update Debian package. Since there are no releases yet, I suppose you would recommend to package HEAD of "master"?

[miekg]

[ Quoting notifications@github.com in "Re: [dns] Please tag releases (#280..." ]

You might find it interesting to read Debian UpstreamGuide...

We have a ticket to
update Debian package. Since there are no releases yet, I suppose you would
recommend to package HEAD of "master"?

yep.

I see the ticket is openend for SkyDNS. SkyDNS follows Go DNS very closely (I
maintain SkyDNS).

/Miek

Miek Gieben

[andrewtj]

On Sun, Nov 1, 2015 at 8:08 PM, Miek Gieben notifications@github.com
wrote:

[ Quoting notifications@github.com in "Re: [dns] Please tag releases
(#280..." ]

As far as I understand,
@miekg shepherds the project along keeping master as sane as possible at
the
bleeding edge of standards, avoiding breaking changes wherever
reasonable, and
with support for the last two versions of Go. That's not a small
commitment.

Yes, this is the "contract" for Go dns master branch.

That probably ought to go in the readme somewhere.

[miekg]

Good point, done via 497abb0