Issue 7225047: code review 7225047: doc: document runtime requirements (Closed)
Descriptiondoc: document runtime requirements
Fixes issue 3897.
Strawman proposal, not ready for submission.
Also adds freebsd/arm to list of supported platforms in install-source.html
Discussion: https://groups.google.com/d/topic/golang-nuts/7JFyFTaqT9w/discussion
Patch Set 1 #Patch Set 2 : diff -r 45a405b5c63a https://code.google.com/p/go #Patch Set 3 : diff -r fe561fd77106 https://code.google.com/p/go #
Total comments: 41
Patch Set 4 : diff -r fe561fd77106 https://code.google.com/p/go #
Total comments: 8
Patch Set 5 : diff -r aee6d7fe395a https://code.google.com/p/go #
Total comments: 5
Patch Set 6 : diff -r 885321ad3873 https://code.google.com/p/go #Patch Set 7 : diff -r 885321ad3873 https://code.google.com/p/go #Patch Set 8 : diff -r 885321ad3873 https://code.google.com/p/go #
Total comments: 4
MessagesTotal messages: 30
https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html File doc/go1platform.html (right): https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode87 doc/go1platform.html:87: <code>windows</code>, Windows XP service pack 2 and above on <code>386</code>. /Windows XP service pack 2/Windows XP Service Pack 3/ http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode88 doc/go1platform.html:88: All <code>amd64</code> versions of Windows are supported. /All <code>amd64</code> versions of Windows are supported./Windows XP Service Pack 2 and above on <code>amd64</code>./ http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode150 doc/go1platform.html:150: <code>windows</code>, Windows XP service pack 2 and above on <code>386</code>. /Windows XP service pack 2/Windows XP Service Pack 3/ http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode151 doc/go1platform.html:151: All <code>amd64</code> versions of Windows are supported. /All <code>amd64</code> versions of Windows are supported./Windows XP Service Pack 2 and above on <code>amd64</code>./ http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean
Sign in to reply to this message.
Microsoft (Windows), Canonical (Ubuntu), etc. assign support end dates to versions of their operating systems. Should Go drop support too?
Sign in to reply to this message.
sorry, i take this discussion to golang-dev (cc: +golang-dev). As i see some important issues worthy to be discussed on golang-dev. We need to determine accurate minimum linux kernel requirement. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html File doc/go1platform.html (right): https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode46 doc/go1platform.html:46: TODO(dfc) MMX ? AVX ? SSE i think we only need a pentium pro class processor, and nothing more. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode49 doc/go1platform.html:49: <code>amd64</code> processors with SSE2 instruction set extensions. SSE2 is mandatory for amd64 processors. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode52 doc/go1platform.html:52: <code>arm</code> processors supporting the ARMv5 or ARMv7 microarchitecture. nitpicking: technically, it's not called microarchitecture, and should just be called architecture. In fact, ARM Holdings sells architectural license to others so some ARM processors are not even using ARM Holding's microarchitecture (one notable examples is StrongARM by DEC). https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode53 doc/go1platform.html:53: ARMv6, most notably the CPU found in the Raspberry Pi are not supported. why? they just have to use software floating point. i don't think that is equivalent to ARMv6 not being supported. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode75 doc/go1platform.html:75: <code>freebsd</code> versions 8.2 and later on <code>386</code> and <code>amd64</code>. version 7 or latter according to http://golang.org/doc/install https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode81 doc/go1platform.html:81: <code>386</code> with kernel 2.6.27 or later, <code>amd64</code> with kernel 2.6.23 or later according to http://golang.org/doc/install https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode82 doc/go1platform.html:82: 2.6.27 or later, and <code>arm</code> with kernel 2.6.35 or later. Older kernel why 2.6.35? also we need glibc-compatible libc. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode87 doc/go1platform.html:87: <code>windows</code>, Windows XP service pack 2 and above on <code>386</code>. i think Go 1.0 still supports windows 2000, although i haven't have chance to verify that. ref: http://golang.org/doc/install https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode88 doc/go1platform.html:88: All <code>amd64</code> versions of Windows are supported. On 2013/01/26 05:56:53, peterGo wrote: > /All <code>amd64</code> versions of Windows are supported./Windows XP Service > Pack 2 and above on <code>amd64</code>./ > http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean Windows XP SP2 and above for desktop, and Windows Server 2003 and above for server. http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=wind... https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode95 doc/go1platform.html:95: in Go 1.0 and adds support for <code>netbsd</code> and <code>openbsd</code> FreeBSD/ARM. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode109 doc/go1platform.html:109: <code>amd64</code> processors with SSE2 instruction set extensions. remove "with SSE2 ISA extensions" as explained above. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode114 doc/go1platform.html:114: correct microarchitecture when compiled from source on the target platform. will automatically choose correct VFP architecture to use when compiled from source on the target platform. For cross compiles, the user needs to specific correct <code>GOARM</code> as explained in section <a href="#??">GOARM</a>. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode129 doc/go1platform.html:129: <code>freebsd</code> versions 8.2 and later on <code>386</code> and we still support FreeBSD 7. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode137 doc/go1platform.html:137: 2.6.27 or later, and <code>arm</code> with kernel 2.6.35 or later. Older kernel i don't what's reason behind 2.6.27 and 2.6.35. FYI, 2.6.27 is released on October 9, 2008 2.6.35 is released on August 1, 2010, which is too recent IMO. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode142 doc/go1platform.html:142: <code>netbsd</code> versions 5.1 (TODO(bsiegert) confirm) and later on we don't support NetBSD 5 any more, 6 is the strict minimum. Go 1.0 might have partial support for NetBSD 5.x. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode146 doc/go1platform.html:146: <code>openbsd</code> version 9000 (TODO(jsing) confirm) and later on 5.2 and above. we need the user to enable rthread manually for previous OpenBSD version in Go 1.0.x. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode150 doc/go1platform.html:150: <code>windows</code>, Windows XP service pack 2 and above on <code>386</code>. On 2013/01/26 05:56:53, peterGo wrote: > /Windows XP service pack 2/Windows XP Service Pack 3/ > http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean we need to decide whether to drop support for windows 2000. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode151 doc/go1platform.html:151: All <code>amd64</code> versions of Windows are supported. On 2013/01/26 05:56:53, peterGo wrote: > /All <code>amd64</code> versions of Windows are supported./Windows XP Service > Pack 2 and above on <code>amd64</code>./ > http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean see above.
Sign in to reply to this message.
Hello go.peter.90@gmail.com, minux.ma@gmail.com (cc: golang-dev@googlegroups.com), I'd like you to review this change to https://code.google.com/p/go
Sign in to reply to this message.
Thank you for your comments. @peter - I do not know which versions of Windows are supported, I'll see what brainman has to say when he is back next week. @minux - i've added a link in the issue description to the discussion on golang-nuts. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html File doc/go1platform.html (right): https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode46 doc/go1platform.html:46: TODO(dfc) MMX ? AVX ? SSE On 2013/01/26 11:29:11, minux wrote: > i think we only need a pentium pro class processor, and nothing more. Done. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode49 doc/go1platform.html:49: <code>amd64</code> processors with SSE2 instruction set extensions. On 2013/01/26 11:29:11, minux wrote: > SSE2 is mandatory for amd64 processors. Do you think it is safe to say all x86_64/amd64 processors are supported ? https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode52 doc/go1platform.html:52: <code>arm</code> processors supporting the ARMv5 or ARMv7 microarchitecture. On 2013/01/26 11:29:11, minux wrote: > nitpicking: technically, it's not called microarchitecture, > and should just be called architecture. > > In fact, ARM Holdings sells architectural license to others > so some ARM processors are not even using ARM Holding's > microarchitecture (one notable examples is StrongARM by DEC). Done. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode53 doc/go1platform.html:53: ARMv6, most notably the CPU found in the Raspberry Pi are not supported. On 2013/01/26 11:29:11, minux wrote: > why? they just have to use software floating point. > i don't think that is equivalent to ARMv6 not being supported. It might just be easier to leave the whole ARMv6/RPi stuff out. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode75 doc/go1platform.html:75: <code>freebsd</code> versions 8.2 and later on <code>386</code> and <code>amd64</code>. On 2013/01/26 11:29:11, minux wrote: > version 7 or latter according to http://golang.org/doc/install Done. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode82 doc/go1platform.html:82: 2.6.27 or later, and <code>arm</code> with kernel 2.6.35 or later. Older kernel On 2013/01/26 11:29:11, minux wrote: > why 2.6.35? For the ARMv5 cas helpers, I thought they were unreliable before .35. > > also we need glibc-compatible libc. Sure, do you have any idea which version ? https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode87 doc/go1platform.html:87: <code>windows</code>, Windows XP service pack 2 and above on <code>386</code>. On 2013/01/26 05:56:53, peterGo wrote: > /Windows XP service pack 2/Windows XP Service Pack 3/ > http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean yup, personally I'd like to see XP be wiped from this earth, but this section is documenting the world as it existed in 2012. I would be happy to change this to vaguer <code>windows</code> non specified. I'll ask brainman for his input next week. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode95 doc/go1platform.html:95: in Go 1.0 and adds support for <code>netbsd</code> and <code>openbsd</code> On 2013/01/26 11:29:11, minux wrote: > FreeBSD/ARM. Done. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode109 doc/go1platform.html:109: <code>amd64</code> processors with SSE2 instruction set extensions. On 2013/01/26 11:29:11, minux wrote: > remove "with SSE2 ISA extensions" as explained above. Done. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode114 doc/go1platform.html:114: correct microarchitecture when compiled from source on the target platform. On 2013/01/26 11:29:11, minux wrote: > will automatically choose correct VFP architecture to use > when compiled from source on the target platform. > For cross compiles, the user needs to specific correct > <code>GOARM</code> as explained in section <a href="#??">GOARM</a>. Done. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode129 doc/go1platform.html:129: <code>freebsd</code> versions 8.2 and later on <code>386</code> and On 2013/01/26 11:29:11, minux wrote: > we still support FreeBSD 7. Done. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode142 doc/go1platform.html:142: <code>netbsd</code> versions 5.1 (TODO(bsiegert) confirm) and later on On 2013/01/26 11:29:11, minux wrote: > we don't support NetBSD 5 any more, 6 is the strict minimum. > Go 1.0 might have partial support for NetBSD 5.x. I believe NetBSD wasn't a supported platform for Go 1.0, so we can avoid mentioning version 5 at all. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode146 doc/go1platform.html:146: <code>openbsd</code> version 9000 (TODO(jsing) confirm) and later on On 2013/01/26 11:29:11, minux wrote: > 5.2 and above. > we need the user to enable rthread manually for previous OpenBSD > version in Go 1.0.x. Done. Again, NetBSD was not supported on Go 1.0 so we can avoid mentioning rthreads.
Sign in to reply to this message.
https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html File doc/go1platform.html (right): https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode49 doc/go1platform.html:49: <code>amd64</code> processors with SSE2 instruction set extensions. On 2013/01/26 12:09:20, dfc wrote: > On 2013/01/26 11:29:11, minux wrote: > > SSE2 is mandatory for amd64 processors. > Do you think it is safe to say all x86_64/amd64 processors are supported ? yes. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode53 doc/go1platform.html:53: ARMv6, most notably the CPU found in the Raspberry Pi are not supported. On 2013/01/26 12:09:20, dfc wrote: > On 2013/01/26 11:29:11, minux wrote: > > why? they just have to use software floating point. > > i don't think that is equivalent to ARMv6 not being supported. > It might just be easier to leave the whole ARMv6/RPi stuff out. yeah, i agree. because the major audience of this document should already been using Go 1.1. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode82 doc/go1platform.html:82: 2.6.27 or later, and <code>arm</code> with kernel 2.6.35 or later. Older kernel On 2013/01/26 12:09:20, dfc wrote: > On 2013/01/26 11:29:11, minux wrote: > > why 2.6.35? > For the ARMv5 cas helpers, I thought they were unreliable before .35. any references? i think i can build and test Go on an older Debian/armel VM with kernel 2.6.32-5-versatile. > > also we need glibc-compatible libc. > Sure, do you have any idea which version ? That's where the problem comes, I don't know exactly what do we expect from the libc in general. I remembered that some reports showed uclibc is unusable?? I'm not sure (I don't use dynamic linked Go programs on embedded systems, but i can try building Go with uclibc if necessary). That's why when i add relevant section to golang.org/doc/install, i simply mention glibc as that's what our builders use. The problem is that there're simply too many libc implementations to choose from, esp. for ARM. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode87 doc/go1platform.html:87: <code>windows</code>, Windows XP service pack 2 and above on <code>386</code>. On 2013/01/26 12:09:20, dfc wrote: > On 2013/01/26 05:56:53, peterGo wrote: > > /Windows XP service pack 2/Windows XP Service Pack 3/ > > http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean > yup, personally I'd like to see XP be wiped from this earth, but this section is > documenting the world as it existed in 2012. I would be happy to change this to please don't drop support for XP, as there are still a lot of installation here. but I don't mind we only support Windows XP SP3 x86 and above. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode88 doc/go1platform.html:88: All <code>amd64</code> versions of Windows are supported. On 2013/01/26 11:29:11, minux wrote: > On 2013/01/26 05:56:53, peterGo wrote: > > /All <code>amd64</code> versions of Windows are supported./Windows XP Service > > Pack 2 and above on <code>amd64</code>./ > > http://windows.microsoft.com/en-US/windows/help/what-does-end-of-support-mean > Windows XP SP2 and above for desktop, and Windows Server 2003 > and above for server. Just FYI, I can't verify XP SP2 x64, but i think 2003 R2 does work. https://codereview.appspot.com/7225047/diff/1002/doc/go1platform.html#newcode142 doc/go1platform.html:142: <code>netbsd</code> versions 5.1 (TODO(bsiegert) confirm) and later on On 2013/01/26 12:09:20, dfc wrote: > On 2013/01/26 11:29:11, minux wrote: > > we don't support NetBSD 5 any more, 6 is the strict minimum. > > Go 1.0 might have partial support for NetBSD 5.x. > I believe NetBSD wasn't a supported platform for Go 1.0, so we can avoid > mentioning version 5 at all. Agree. https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html File doc/go1platform.html (right): https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html#newcode45 doc/go1platform.html:45: <code>386</code> processors of Pentium class or higher. we are using MOVQ and EMMS for sync/atomic.LoadUint64, so the minimum requirement is Pentium MMX. https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html#newcode51 doc/go1platform.html:51: <code>arm</code> processors supporting the ARMv5 or ARMv7 architecture. ARMv5E and ARMv6 (both without VFP support), and ARMv7. https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html#newcode93 doc/go1platform.html:93: operating systems, and support for <code>freebsd/arm</code>. the FreeBSD/ARM support is still preliminary, but I will finish it once I get my RPi. https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html#newcod... doc/go1platform.html:107: <code>amd64</code> processors with SSE2 instruction set extensions. ? https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html#newcod... doc/go1platform.html:110: <code>arm</code> processors supporting the ARMv5, ARMv6, and ARMv7 architecture. s/ARMv5/ARMv5E/ https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html#newcod... doc/go1platform.html:113: platform. For cross compilation, the target architecture must be supplied via i still think GOARM is a misnomer, as it really should be named GOVFP. I do think GOARM could be used later for what it really is for-- ARM architecture versions. Given that GOARM is not covered by Go 1 contract, I still propose we rename it to GOVFP, deprecate its use in Go 1.1 and remove (or perhaps assign new meanings to) it in Go 1.2. https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html#newcod... doc/go1platform.html:147: <code>openbsd</code> version 5.2 and above on <code>amd64</code>. i believe we support OpenBSD/386 as jsing once gave me benchmark data on it for CL 6820120. The minimum requirement is the same for amd64 and i386.
Sign in to reply to this message.
some random thoughts: 1. i think we need to have a section to tell the user how to check if a machine has some feature (e.g. MMX, SSE2, VFPv3...) on all supported systems. 2. should we have builders that help testing on the minimum supported systems? if we make guarantee like this in the document, imo we should do so. 3. we deprecate GOARM in Go 1.1, and instead favor GOVFP. an alternative would be, introduce some structures to it, so that we can really represent ARMv7 w/o VFP and ARMv7 with VFP and ARMv7 with VFP and NEON. Because we could generate better code for ARMv6 and above, but I don't feel it's right to drop support for ARMv5 now. 4. We need builder for OpenBSD/386.
Sign in to reply to this message.
> please don't drop support for XP, as there are still a lot of installation here. I second this sentiment. There are still a lot of windows xp computers out there (I still have one). Especially in a corporate world. Some windows developers targets "all windows users" and would not touch tool that does not provide this compatibility. Most of our code works fine on windows 2000, it is silly to just disregard that. Alex
Sign in to reply to this message.
On Sun, Jan 27, 2013 at 5:29 AM, <alex.brainman@gmail.com> wrote: > please don't drop support for XP, as there are still a lot of >> > installation here. > I second this sentiment. There are still a lot of windows xp computers > out there (I still have one). Especially in a corporate world. Some > windows developers targets "all windows users" and would not touch tool > that does not provide this compatibility. Most of our code works fine on > windows 2000, it is silly to just disregard that. > so you think we should keep supporting windows 2000?
Sign in to reply to this message.
https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html File doc/go1platform.html (right): https://codereview.appspot.com/7225047/diff/10001/doc/go1platform.html#newcode27 doc/go1platform.html:27: to the tool chain and runtime flavor, and indicate a 32bit Intel instruction 32-bit, here and elsewhere
Sign in to reply to this message.
I doubt many people have win2k, so its support is not critical. Let's go with xp and up. I am more concerned about windows 8. Does it works there? I don't know anyone, who has windows 8 with go installation on it. Alex
Sign in to reply to this message.
On Sun, Jan 27, 2013 at 5:47 AM, <alex.brainman@gmail.com> wrote: > I doubt many people have win2k, so its support is not critical. Let's go > with xp and up. > sure. fine with me. > > I am more concerned about windows 8. Does it works there? I don't know > anyone, who has windows 8 with go installation on it. > Me neither. I will post a question to golang-nuts.
Sign in to reply to this message.
Please take another look. I am experimenting with a table layout for the operating system matrix. This might need some help from the website stylesheet to look decent. Still to be finalised * kernel version for linux, do we say minimum and/or recommended ? Can we make a change between 1.0 and 1.1 ? * which windows versions, I don't think we can say 'or later' in all cases, do we need to list them all ?
Sign in to reply to this message.
https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html File doc/go1platform.html (right): https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html#newcode22 doc/go1platform.html:22: supported during the lifetime of Go 1. Go 1 is a specification and standard library backwards compatibility promise, not a specific release of software. I think this document would be better off stating that it applies to the gc and gccgo toolchains. There may be an alternate toolchain some time in the future which doesn't follow the rules in this document.
Sign in to reply to this message.
i'd like we first show a true system support matrix
(with colors indicating whether the support is complete,
with or w/o cgo, etc...)
For example:
Linux Darwin FreeBSD Windows
386 ok ok ok ok
amd64 ok ok ok ok
arm ok n/a no cgo n/a
legend: green - production support, yellow - experimental
red - not available
and a detailed explanations section follows that matrix
and give accurate details (we should make each matrix
cell clickable, and link to corresponding subsection
below).
https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html
File doc/go1platform.html (right):
https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html#newcode16
doc/go1platform.html:16: TODO(dfc) integrate supported gccgo platforms.
should confirm with iant. below is my educated guess:
Linux (x86, x86_64, arm, mips, [mips64?] and alpha at least)
Solaris (x86, x86_64, sparc and sparc64)
RTEMS (x86 ??)
Irix (x86_64 ??)
definitely not supported (yet):
*BSD (NetBSD could be supported before Go 1.1)
Darwin (porting in progress)
Windows
Sign in to reply to this message.
On 2013/01/27 09:11:46, dfc wrote: ... > * which windows versions, I don't think we can say 'or later' in all cases, do > we need to list them all ? Looking at the issue you are fixing, I do not see any particular need to provide many details as far as windows os concerned. I think we should say that windows is supported on 386 and amd64, and not supported on arm. Maybe we could even say "windows 32-bit" for 386 and "windows 64-bit" for amd64, because 386 and amd64 terms aren't used in windows world, as far as I know it. I don't think we need to provide any more details then that. We make every effort to support all windows versions. As far as I know, there aren't any show stoppers. If we will find something different in the future, we could change this text then. Alex
Sign in to reply to this message.
https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html File doc/go1platform.html (right): https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html#newcode7 doc/go1platform.html:7: This page documents the minimum, and in some cases maximum, requirements This needs to be more specific. Is it about programs produced by the gc or gccgo compilers? Do we need separate documents for each? It is also unclear to me whether this should be about where the compiler will run, vs where the compiled go code will run. Presumably the former is a subset of the latter. https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html#newcode20 doc/go1platform.html:20: In line with the source level compatibility goals of Go 1, hardware and s/hardware/processor architectures/ https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html#newcode26 doc/go1platform.html:26: <h2 id="go1">Go 1.0</h2> The document should not be oriented around Go versions. Go 1.x should be a given; that's all this document should cover. Differences between 1.0 and 1.1 may be annotated with an asterisk or other such character, where the footnote explains when support was added. We should assume that anyone reading this document is willing to use the latest version of Go.
Sign in to reply to this message.
On 2013/01/29 04:58:05, adg wrote: > https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html > File doc/go1platform.html (right): > > https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html#newcode7 > doc/go1platform.html:7: This page documents the minimum, and in some cases > maximum, requirements > This needs to be more specific. Is it about programs produced by the gc or gccgo > compilers? Do we need separate documents for each? I don't know, I think gccgo needs to be documented elsewhere as the set of supported platforms is governed by gcc to some extent. I will reword this to document only the gc compiler suite. > It is also unclear to me whether this should be about where the compiler will > run, vs where the compiled go code will run. Presumably the former is a subset > of the latter. > > https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html#newcode20 > doc/go1platform.html:20: In line with the source level compatibility goals of Go > 1, hardware and > s/hardware/processor architectures/ > > https://codereview.appspot.com/7225047/diff/12002/doc/go1platform.html#newcode26 > doc/go1platform.html:26: <h2 id="go1">Go 1.0</h2> > The document should not be oriented around Go versions. Go 1.x should be a > given; that's all this document should cover. > > Differences between 1.0 and 1.1 may be annotated with an asterisk or other such > character, where the footnote explains when support was added. > > We should assume that anyone reading this document is willing to use the latest > version of Go. Yup, but internally, on golang-dev there have been debates about which linux kernel version, which SSE2 version etc. I hoped by documenting Go 1.0 retroactively we could resolve those debates. I think it turns out it doesn't matter. I'll rework the table to show only only Go 1.1 and add footnotes.
Sign in to reply to this message.
Hello adg@golang.org (cc: golang-dev@googlegroups.com), Please take another look.
Sign in to reply to this message.
why all reviewers but adg are removed? On 2013/01/27 12:56:02, minux wrote: > i'd like we first show a true system support matrix > (with colors indicating whether the support is complete, > with or w/o cgo, etc...) > > For example: > Linux Darwin FreeBSD Windows > 386 ok ok ok ok > amd64 ok ok ok ok > arm ok n/a no cgo n/a > > legend: green - production support, yellow - experimental > red - not available > > and a detailed explanations section follows that matrix > and give accurate details (we should make each matrix > cell clickable, and link to corresponding subsection > below). what's your opinion about this suggestion? I think we'd better show a clearer (and simpler) view first, and then add in the details.
Sign in to reply to this message.
On Sat, Feb 2, 2013 at 12:50 PM, <minux.ma@gmail.com> wrote: > why all reviewers but adg are removed? I just wanted to assign adg the task of being the final arbiter. You are all still welcome to review and make comments. Because codereview adds anyone who replies to the R= line, it can get a bit overwhelming. Russ
Sign in to reply to this message.
> what's your opinion about this suggestion? > I think we'd better show a clearer (and simpler) view > first, and then add in the details. I am not keen on using color to distinguish between the options as it does not translate well onto the printed page, color is also an issue for 1/12th of the population (lesser for women) who find the usual web colors hard to distinguish. I think bold, italics, or strikethrough might be better. As the lack of cgo is only an issue for a smaller % of the platforms, we could handle that with a footnote as it is the exception these days.
Sign in to reply to this message.
On Sun, Feb 3, 2013 at 8:12 AM, Dave Cheney <dave@cheney.net> wrote: > > what's your opinion about this suggestion? > > I think we'd better show a clearer (and simpler) view > > first, and then add in the details. > > I am not keen on using color to distinguish between the options as it > does not translate well onto the printed page, color is also an issue > for 1/12th of the population (lesser for women) who find the usual web > colors hard to distinguish. I think bold, italics, or strikethrough > might be better. > ok. however, using color is a minor point and my main point is we use a matrix (table) to give an high level system support overview and then provide details below. the individual cells of the table also serve as a link to corresponding section below should the user become interested in the details, and i guess most user don't need (or want) details such as windows NT 4 is not supported and so on.
Sign in to reply to this message.
On 2013/02/03 17:10:46, minux wrote: > On Sun, Feb 3, 2013 at 8:12 AM, Dave Cheney <mailto:dave@cheney.net> wrote: > > > > what's your opinion about this suggestion? > > > I think we'd better show a clearer (and simpler) view > > > first, and then add in the details. > > > > I am not keen on using color to distinguish between the options as it > > does not translate well onto the printed page, color is also an issue > > for 1/12th of the population (lesser for women) who find the usual web > > colors hard to distinguish. I think bold, italics, or strikethrough > > might be better. > > > ok. however, using color is a minor point and my main point is we > use a matrix (table) to give an high level system support overview > and then provide details below. I agree that the matrix is a good idea. Instead of colors, the words could be "ok", "exp", "n/a", with footnotes for platforms with exceptions like freebsd-arm.
Sign in to reply to this message.
> I agree that the matrix is a good idea. Instead of colors, the words > could be "ok", "exp", "n/a", with footnotes for platforms with > exceptions like freebsd-arm. Sure, i'll give it a crack after work tonight. Could I ask for some love for the stylesheet to make tables a bit nicer ?
Sign in to reply to this message.
On 4 February 2013 12:16, Dave Cheney <dave@cheney.net> wrote: > Sure, i'll give it a crack after work tonight. Could I ask for some > love for the stylesheet to make tables a bit nicer ? > Sure. Try with the styles used by go1.html, as a start.
Sign in to reply to this message.
https://codereview.appspot.com/7225047/diff/22001/doc/go1runtime.html File doc/go1runtime.html (right): https://codereview.appspot.com/7225047/diff/22001/doc/go1runtime.html#newcode18 doc/go1runtime.html:18: should continue to be supported during the lifetime of Go 1. Additional I am not comfortable with this. This document should be "Here's what is currently supported by the gc compiler", not "Here's what we promise to support." In a few years' time it is not unlikely that we might phase out support for older kernels or processors. I don't want to conflate the requirements of the gc compiler with the Go 1 language and library guarantees. Please rename the doc "gcruntime.html" or similar, and drop this paragraph. https://codereview.appspot.com/7225047/diff/22001/doc/go1runtime.html#newcode25 doc/go1runtime.html:25: The Go 1 compiler suite produce binary executables compatible with the s_Go 1_<code>gc</code>_ https://codereview.appspot.com/7225047/diff/22001/doc/go1runtime.html#newcode31 doc/go1runtime.html:31: <code>386</code> processors with a 387 floating point coprocesssor. Support Does this mean I could actually run Go on a 486? Should we specify an actual minimum processor? I feel like "Intel" should be mentioned here. https://codereview.appspot.com/7225047/diff/22001/doc/go1runtime.html#newcode51 doc/go1runtime.html:51: The Go 1 runtime is compatible with the following operating system releases. s/ 1//
Sign in to reply to this message.
Replacing golang-dev with golang-codereviews.
Sign in to reply to this message.
|
