diff options
author | Russ Cox <rsc@golang.org> | 2020-03-15 15:50:36 -0400 |
---|---|---|
committer | Russ Cox <rsc@golang.org> | 2020-03-17 20:58:46 +0000 |
commit | 972d42d925e6cae3f8eebd9b21d445e06c2eb386 (patch) | |
tree | 737af27f0d49318b612efec874b1d1328c699d1a /content/go1-preview.article | |
parent | faf1e2da2d911edc717993e8edb24fe88f99b2b5 (diff) |
content: rename articles to reinforce convention of short URLs
The Go blog started out on Blogger
(http://web.archive.org/web/20100325005843/http://blog.golang.org/).
Later, we moved to the current self-hosted blog server
with extra Go-specific functionality like playground snippets.
The old Blogger posts have very long URLs that Blogger chose
for us, such as "go-programming-language-turns-two" or
"two-go-talks-lexical-scanning-in-go-and", predating
the convention of giving posts shorter, more share-friendly,
typeable names.
The conversion of the old Blogger posts also predated
the convention of putting supporting files in a subdirectory.
The result is that although we've established new conventions,
you wouldn't know by listing the directory - the old Blogger
content presents a conflicting picture.
This commit renames the posts with very long names
to have shorter, more share-friendly names, and it moves
all supporting files to subdirectories. It also adds a README
documenting the conventions.
For example, blog.golang.org/go-programming-language-turns-two
is now blog.golang.org/2years, matching our more recent birthday
post URLs, and its supporting files are moved to the new 2years/ directory.
The old URLs redirect to the new ones.
Change-Id: I9f46a790c2c8fab8459aeda73d4e3d2efc86d88f
Reviewed-on: https://go-review.googlesource.com/c/blog/+/223599
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Diffstat (limited to 'content/go1-preview.article')
-rw-r--r-- | content/go1-preview.article | 49 |
1 files changed, 49 insertions, 0 deletions
diff --git a/content/go1-preview.article b/content/go1-preview.article new file mode 100644 index 0000000..6e3f474 --- /dev/null +++ b/content/go1-preview.article @@ -0,0 +1,49 @@ +# A preview of Go version 1 +5 Oct 2011 +Tags: go1, release +Summary: What the Go team is planning for Go version 1. +OldURL: /preview-of-go-version-1 + +Russ Cox + +## + +We want to be able to provide a stable base for people using Go. +People should be able to write Go programs and expect that they will continue +to compile and run without change, +on a timescale of years. +Similarly, people should be able to write books about Go, +be able to say which version of Go the book is describing, +and have that version number still be meaningful much later. +None of these properties is true for Go today. + +We propose to issue a Go release early next year that will be called “Go version 1”, +Go 1 for short, that will be the first Go release to be stable in this way. +Code that compiles in Go version 1 should, +with few exceptions, continue to compile throughout the lifetime of that version, +as we issue updates and bug fixes such as Go version 1.1, 1.2, and so on. +It will also be maintained with fixes for bugs and security flaws even as +other versions may evolve. +Also, production environments such as Google App Engine will support it +for an extended time. + +Go version 1 will be a stable language with stable libraries. +Other than critical fixes, changes made to the library and packages for versions 1.1, +1.2 and so on may add functionality but will not break existing Go version 1 programs. + +Our goal is for Go 1 to be a stable version of today’s Go, +not a wholesale rethinking of the language. +In particular, we are explicitly resisting any efforts to design new language +features “by committee.” + +However, there are various changes to the Go language and packages that +we have intended for some time and prototyped but have not deployed yet, +primarily because they are significant and backwards-incompatible. +If Go 1 is to be long-lasting, it is important that we plan, +announce, implement, and test these changes as part of the preparation of Go 1, +rather than delay them until after it is released and thereby introduce +divergence that contradicts our goals. + +Today, we are publishing our preliminary [plan for Go 1](https://docs.google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE) +for feedback from the Go community. +If you have feedback, please reply to the [thread on the golang-nuts mailing list](http://groups.google.com/group/golang-nuts/browse_thread/thread/badc4f323431a4f6). |