Changes to the Release Process
Andrew Gerrand
motivation is to make it easier for Go users to keep a stable,
up-to-date Go install without having to update their code every week.
The core idea is to continue to release on a weekly basis, but to
periodically mark hand-picked releases as stable. Users who only want
to update every month or two can work at the stable tag, while those
who want to live on the edge can stay with the weeklies.
Implementation:
What we currently call "release" will now be called "weekly". Weeklies
will be issued with the same regularity as in the past. All existing
tags will be renamed (s/release/weekly/).
The "release" tag will effectively mean "stable". A weekly is blessed
as a release after it has proven itself to be the most stable
candidate of the past few weeks. The criterion for selecting a release
are a broad range of factors, so there should be no hard rule about
regularity, but the idea is to nominate a stable release every 1-2
months. Therefore, the current release will typically be a bit older
than the current weekly.
Weeklies will be tagged as:
weekly.YYYY-MM-DD (as per the existing regime)
with the current weekly tagged as "weekly".
Releases will be tagged as:
release.YYYY.N
where N starts at 0 and is incremented with each release. The current
release is tagged as "release".
The net effect is that users who usually "hg update release" will see
less frequent breakages. Those who want to follow development more
closely should switch to "hg update weekly". Those that live on the
bleeding edge will continue to "hg update" as normal.
golang.org will be kept at "release" the tag.
Feedback?
Andrew
Robert Griesemer
David Symonds
Seems like a good idea if enough people track "weekly" to catch problems.
> Releases will be tagged as:
> release.YYYY.N
> where N starts at 0 and is incremented with each release. The current
> release is tagged as "release".
I think I'd prefer this stay at release.YYYY-MM-DD so that it's easy
to identify when it was from. If it's December 2011, "2011.2" could
mean a long time ago or something quite recent.
Dave.
Gustavo Niemeyer
ability to better choose what they're looking for is a plus.
> golang.org will be kept at "release" the tag.
This is the only point which feels like a drawback. People already
stumble every once in a while on the differences between tip and
what's in golang.org. I expect this will get worse with the
additional delay.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter
Andrew Gerrand
> Most of your proposal is mostly informational, so giving users the
> ability to better choose what they're looking for is a plus.
>
>> golang.org will be kept at "release" the tag.
>
> This is the only point which feels like a drawback. People already
> stumble every once in a while on the differences between tip and
> what's in golang.org. I expect this will get worse with the
> additional delay.
As with anything, there are tradeoffs. As the Go community grows there
will be proportionally fewer who want to live at the bleeding edge. I
think it's appropriate for golang.org to appeal to the broader
audience.
By making the release tag advance more slowly (or, rather, in broader
leaps) the distinction between "release" and "tip" should become more
obvious. Those who are clever enough to live at "tip" or "weekly"
should be able to run their own instance of godoc.
Andrew
Andrew Gerrand
There are other directions we could take this, too. How about
release.X.Y
where X is the year's chinese zodiac sign, and Y is the sign of the
greek zodiac.
For example, the current release would be:
release.鼠.♒
Andrew
mattn
yiyus
> > golang.org will be kept at "release" the tag.
>
> This is the only point which feels like a drawback. People already
> stumble every once in a while on the differences between tip and
> what's in golang.org. I expect this will get worse with the
> additional delay.
>
process is adopted, a weekly.golang.org. Is this feasible?
Gustavo Niemeyer
> checking as stable.(?)
Yes, I agree with question mark at the end.
> I think that you've better to take more time for design or coding. i.e, I
> think that the "weekly release" should be semiautomatically. No release note
> for it. Don't hurry for it. :)
It is already semiautomatic. Andrew just takes some time every week
to tag the weekly, and to assemble the release notes from the commits.
I appreciate a lot Andrew's time on this, as it provides a very nice
heartbeat.
Dave Cheney
> to tag the weekly, and to assemble the release notes from the commits.
> I appreciate a lot Andrew's time on this, as it provides a very nice
> heartbeat.
I don't have a position in the discussion but wanted to echo Gustavos note of thanks to Andrew for his efforts as release manager.
Andrew Gerrand
> It would be nice to have a tip.golang.org and, if the new release
> process is adopted, a weekly.golang.org. Is this feasible?
It would be nice, but rolling out the releases to golang.org is -
believe it or not - one of the more time-consuming parts of issuing a
release. If someone else wants to run an instance of godoc at
tip/weekly somewhere (appropriately labelled), though, that would be
great.
Andrew
Andrew Gerrand
FWIW, my rationale for picking this scheme is it being easier to
remember the exact release tag. I'm much more likely to remember that
we're at 2011.7 than 2011.2011-06-15. If we only do (say) 12 releases
a year the extra digits are just noise.
Andrew
Nigel Tao
> FWIW, my rationale for picking this scheme is it being easier to
> remember the exact release tag. I'm much more likely to remember that
> we're at 2011.7 than 2011.2011-06-15. If we only do (say) 12 releases
> a year the extra digits are just noise.
If you are going to go this way, maybe 2011.r7 would be less likely to
be confused as July 2011.
Gustavo Niemeyer
I'm already running godoc at goneat.org, with some redirects back to golang.org atm. I'll put it to update from tip.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter
Dave Cheney
> believe it or not - one of the more time-consuming parts of issuing a
> release. If someone else wants to run an instance of godoc at
> tip/weekly somewhere (appropriately labelled), though, that would be
> great.
>
> Andrew
I'm happy to volunteer to run a weekly godoc instance.
Cheers
Dave
Andrew Gerrand
That's a good idea.
Andrew
魏仁言
Gustavo Niemeyer
> golang.org atm. I'll put it to update from tip.
That's done. goneat.org now updates every 15 minutes from tip.
Andrew Gerrand
>> I'm already running godoc at goneat.org, with some redirects back to
>> golang.org atm. I'll put it to update from tip.
>
> That's done. goneat.org now updates every 15 minutes from tip.
Cool! Very handy.
You might want to disambiguate this page from the real golang.org, in
a couple of ways:
- change doc/logo.png so that it includes a big red "TIP!" or something,
- change this line in lib/godoc/godoc.html
<a id="logo-box" href="/"></a>
to
<a id="logo-box" href="http://golang.org/"></a>
so that when the logo is clicked you get the real golang.org
- add a robots.txt file to the goroot containing
User-agent: *
Disallow: /
to prevent the site from showing up in search results.
If you wanted to go further, you could replace the entire
doc/root.html with something that describes that this isn't the real
golang.org, and explains what it is.
Andrew
Gustavo Niemeyer
>
> You might want to disambiguate this page from the real golang.org, in
> a couple of ways:
Yeah, I imagine the confusion there won't be beneficial. I'll tweak
a few things soonish to make it more obvious that this is not the official
page. Thanks for these suggestions.
Gustavo Niemeyer
> User-agent: *
> Disallow: /
> to prevent the site from showing up in search results.
I don't think this is working. It's showing it inside the HTML
template. Will probably have to put it in haproxy at the front.
Andrew Gerrand
>> - add a robots.txt file to the goroot containing
>> User-agent: *
>> Disallow: /
>> to prevent the site from showing up in search results.
>
> I don't think this is working. It's showing it inside the HTML
> template. Will probably have to put it in haproxy at the front.
The alternative is to add an exception in the godoc source, which
seems like a reasonable idea. We already keep favicon.ico in GOROOT.
I'll mail a CL to gauge reactions.
Gustavo Niemeyer
> seems like a reasonable idea. We already keep favicon.ico in GOROOT.
> I'll mail a CL to gauge reactions.
I was pondering about the same. I suggest bundling the deny-all file
as well, and handling it in a custom way for golang.org, rather than
expecting everyone to disable it.
Andrew Gerrand
>> The alternative is to add an exception in the godoc source, which
>> seems like a reasonable idea. We already keep favicon.ico in GOROOT.
>> I'll mail a CL to gauge reactions.
>
> I was pondering about the same. I suggest bundling the deny-all file
> as well, and handling it in a custom way for golang.org, rather than
> expecting everyone to disable it.
A good idea.
Florian Weimer
> - add a robots.txt file to the goroot containing
> User-agent: *
> Disallow: /
> to prevent the site from showing up in search results.
This doesn't work with the Google engine. It shows links in search
results even if its crawlers have never downloaded them.
You have to use HTML metatags to exclude pages from the index. You
cannot use the robots.txt file above, otherwise the crawlers will
never see the tags.
Nigel Tao
> - Nigel's proposed versioning scheme
On further thoughts I'd drop the dot entirely so that it's "2011r7"
and not "2011.r7".
ka...@golang.org
On Feb 18, 4:01 am, Nigel Tao <nigel.tao.gn...@gmail.com> wrote:
> If you are going to go this way, maybe 2011.r7 would be less likely to
> be confused as July 2011.
One suggestion: add a golang-annouce mailing list that only broadcasts
the releases.
This sounds like the perfect solution for our update problem.
Specifically I like:
documentation)
And obviously changes like the one to channel syntax would span two
releases to make it possible to transition reliably.
Kai
Andrew Gerrand
release.1 and so on. Although it would make sense to start at some
number other than 1, so that people don't get the wrong idea (this is
_not_ Go version 1.0).
We could start at 54, as there have been 53 releases so far.
Andrew
Gustavo Niemeyer
> release.1 and so on. Although it would make sense to start at some
> number other than 1, so that people don't get the wrong idea (this is
> _not_ Go version 1.0).
>
> We could start at 54, as there have been 53 releases so far.
0.54 then?
Andrew Gerrand
>> I'm thinking of dropping the year entirely, so releases would be
>> release.1 and so on. Although it would make sense to start at some
>> number other than 1, so that people don't get the wrong idea (this is
>> _not_ Go version 1.0).
>>
>> We could start at 54, as there have been 53 releases so far.
>
> 0.54 then?
The decimal doesn't make sense. Release 0.55 is not 1/100th closer
than 0.54 to 1.0.
release.54 is just a number. release.55 is just the one after 54, and
there will be nothing special about release.100. (except that we will
have released regularly for another 4 years to get there!)
Perhaps when things get really stable we'll consider adding another
type of tag, "stable" for example, that denotes a Go release for the
ages. It's unclear when that will be, or if it will be necessary at
all.
Andrew
Gustavo Niemeyer
> than 0.54 to 1.0.
Yes, exactly. Release numbers are not decimals, otherwise your kernel
wouldn't be 2.6.X, and no software would ever go from 0.9 to 0.10.
0 is just a number.. 54 is just a number. 0.54 is a well known format
for a software version before it reaches 1.0.
Lorenzo Stoakes
> 0 is just a number.. 54 is just a number. 0.54 is a well known format
> for a software version before it reaches 1.0.
Are we planning to eventually release a 1.0? Using 0.x implies that
the current version is an at least unstable if not, a pre-release
version. It certainly implies that eventually there'll be a 1.0
version which we assert is the 'proper' release - is this something we
want? :-)
--
Lorenzo Stoakes
http://www.codegrunt.co.uk
Lorenzo Stoakes
> This is probably enough bikeshedding about
> the format of revision numbers. Andrew will
> make a decision and we can move on to more
> important things.
>
:-) I didn't know you could use 'bikeshedding' as a verb, nice. And
agreed, obviously a trivial detail of the colour of the bikeshed
variety.
Russ Cox
the format of revision numbers. Andrew will
make a decision and we can move on to more
important things.
Russ