where is an online version of older versions like 1.8 1.6 golang pkg doc ?

[derek]

like for 1.8 1.6

for archeology and other reasons, I am researching a in-house software
written in Golang1.6
want an online version of golang1.6 doc?

https://golang.org/doc/go1.6/pkg/encoding/json/

https://golang.org/pkg/encoding/json/ as I'm checking here is always
pointing to latest version?


Like for Nodejs, and Python and many other language has permanent
archived docs for olders versions:

https://nodejs.org/docs/v8.4.0/api/http2.html is permanent URL for
nodejs v8.4.0

https://nodejs.org/api/http2.html is always pointing to latest version



Thanks;

[Ian Lance Taylor]

We don't have that. You can build it yourself easily enough: clone
the git repo, check out 1.6 and run godoc with the -goroot option
pointing at that directory.

Ian

[derek]

On Thu, Jan 18, 2018 at 7:39 PM, Ian Lance Taylor <ia...@golang.org> wrote:
>> Like for Nodejs, and Python and many other language has permanent
>> archived docs for olders versions:
>>
>> https://nodejs.org/docs/v8.4.0/api/http2.html is permanent URL for
>> nodejs v8.4.0
>>
>> https://nodejs.org/api/http2.html is always pointing to latest version
>
> We don't have that. You can build it yourself easily enough: clone
> the git repo, check out 1.6 and run godoc with the -goroot option
> pointing at that directory.

I know how to set up a godoc site locally, but the problem then is not
Google searchable... harder to share via a single link about a
historic library function design...
So I prefer if anyone knows a 3rd party godoc service online for a
longer period?

And question to the ones behind the official golang.org/doc/.. , Is
there a reason intentionally not doing so? for the archived docs for
older versions?
It's unbelievable not providing any information online about historic
versions, all because relatively young age?

I know the Go designer's goal for 1.x at least is to be backward
compatible for all historic versions down to 1.0?
So when every newer 1.x version release, it's kind of calling everyone
to upgrade,
But if suppose there's a Go 1.x version market share research, I don't
believe the current latest 1.9 has taken all 100% of share? The Go1.8
may still have 20% and Go1.6 10% ?

I don't have the exact numbers, but The archived docs for an older
version still must have some value;

In the longer future, when Go 2 released, it can't take 100% market
share at day1, right? it might take some years to convince every Go
user to upgrade, Would you have an archived godoc for the last 1.x ?


To any 3rd party Go related site owners, would you like to setup such
archives service?

[Ian Lance Taylor]

Perhaps. It's certainly worth considering.

Maintaining online docs for older Go versions sounds like a fine idea
to me. It also sounds like work that somebody has to do.

> To any 3rd party Go related site owners, would you like to setup such
> archives service?

Sounds like a good approach. Or I'm also open to someone writing the
necessary code for golang.org.

Ian

[Florin Pățan]

I think this would further encourage people to be lazy and not upgrade to newer Go versions.

This always leads to problems, especially when things like tooling is involved, and especially

when the debugger side of Go improved so much between versions.

I always liked the fact that Go only shows the docs for the current version, forcing everyone

else to either upgrade or run their own godoc locally for their Go version.

As such, I think it would be a mistake to support anything else but the current version (and tip, ofc).

[Ignacio Gómez]

I think this old discussion about dropping support for ARMv5 (https://github.com/golang/go/issues/17082) makes a point for having docs for older Go versions. It's not always a matter of laziness, sometimes there's no choice. Yeah, the poor lad inheriting a legacy system may and probably will have to generate docs locally, and it takes work and time to maintain docs archives, but if someone is willing to do it, I think there are good cases for it.

[andrey mirtchovski]

Having an option to link to old docs on golang.org (say
golang.org/pkg/something?tag=1.6.0) will result in people linking to
that option, crawlers storing that option, search engines pointing to
that option, and articles, help information and whatever else online
pinning themselves to that option.

This is not ideal in the long term. There is already a way to
reference that info without forcing it on anyone else: local godoc, or
archive.org.

A site disjoint from golang.org/godoc.org that provides the same
service would be agreeable as long as it doesn't supplant the
original.

[paul.to...@gmail.com]

Having an option to link to old docs on golang.org (say

golang.org/pkg/something?tag=1.6.0) will result in people linking to
that option, crawlers storing that option,  search engines pointing to
that option, and articles, help information and whatever else online
pinning themselves to that option.

I agree that this can be frustrating, as with e.g. postgresql documentation. But there exists a solution, at least to some of these problems: link rel="canonical" : https://support.google.com/webmasters/answer/139066?hl=en

Cheers,

Paul

[derek]

On Fri, Jan 19, 2018 at 10:07 AM, Ian Lance Taylor <ia...@golang.org> wrote:
> Sounds like a good approach. Or I'm also open to someone writing the
> necessary code for golang.org.

I just started this approach simply serving static html files:

https://golangdoc.github.io/pkg/1.10beta2/
https://golangdoc.github.io/pkg/1.8.5/
https://golangdoc.github.io/pkg/1.8/
https://golangdoc.github.io/pkg/1.6/

Only the doc under pkg/ works so far, not any src/ code yet (some
generated html for src/ are too big, I'm not sure how to handle
efficiently),
for my own use case, the pkg/ doc is most often looked up as reference;

On Friday, January 19, 2018 at 3:54:34 PM UTC-8, Florin Pățan wrote:
> I think this would further encourage people to be lazy and not upgrade to newer Go versions.

Development within corporate has a nature of being conservative; you
can't simply force everyone to upgrade

As the Golang grows to age 10+; at some point, you will have to handle
the historic versions; I still hope this can be handled by official
golang.org/

At least so far, I can simply share by a single link to friends of
these links, and these are permanent links, public to Google search

https://golangdoc.github.io/pkg/1.10beta2/strings/index.html#Builder
(the one added in Go1.10)
https://golangdoc.github.io/pkg/1.10beta2/sync.html#Map
(this one added in Go1.9)
https://golangdoc.github.io/pkg/1.8/sort/index.html#Slice
(this one added in Go1.8)


I am not subscribing the whole golang-nuts@ ; so please copy me if you
want me to report issues to me.

[Garian Nobinger]

Thank you derek, your references just saved me some headache.