Go Release Cycle

[Andrew Gerrand]

Here's a proposed release timeline for 1.2 and future major Go releases.

https://docs.google.com/document/d/106hMEZj58L9nq9N9p7Zll_WKfo-oyZHFyI6MttuZmBU/edit?usp=sharing

Your comments welcome.

Andrew

[Dave Cheney]

This is excellent, thank you for communicating this publicly, it sounds like an good plan. 

Has any consideration been given to bug fix releases in the 1.1 series? I would like to see an active stable branch maintained throughout the 1.2 dev cycle and fixes back ported to the 1.1 branch continually rather than at fixed points as was the case during 1.0.x. 

I think maintaining a stable branch will make 1.1 point releases easier and will also make it easier for people with critical 1.1 bug to validate a fix without their only choice being to jump onto trunk. 

Cheers

Dave

--
 
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andrew Gerrand]

On 17 May 2013 21:08, Dave Cheney <da...@cheney.net> wrote:

Has any consideration been given to bug fix releases in the 1.1 series? I would like to see an active stable branch maintained throughout the 1.2 dev cycle and fixes back ported to the 1.1 branch continually rather than at fixed points as was the case during 1.0.x. 

I think maintaining a stable branch will make 1.1 point releases easier and will also make it easier for people with critical 1.1 bug to validate a fix without their only choice being to jump onto trunk. 

I would prefer to take the opposite approach: if there is sufficient motivation for a minor release (to fix a critical bug), then that release should contain only that fix. No docs. No other fixes.

This proposal aims to increase the frequency of major releases, and to make minor releases less important. If we get some momentum up and iron out the process, it's conceivable that we could move to a 4-month release cycle, issuing 3 major releases per year. We should see how the 6 month thing goes first, of course.

Andrew

[Ian Lance Taylor]

On Fri, May 17, 2013 at 9:13 PM, Andrew Gerrand <a...@google.com> wrote:
>
> I would prefer to take the opposite approach: if there is sufficient
> motivation for a minor release (to fix a critical bug), then that release
> should contain only that fix. No docs. No other fixes.

I concur. There are already at least two bug fixes that should go
into a Go 1.1.1 release (I've marked the corresponding issues on the
issue tracker), but I don't think anything other than those fixes
should go in.

Ian

[Dave Cheney]

Thank you for your replies. I agree that your approach has a lower
overhead and reduces the number of versions that people can possibly
be using, so let's give it a shot.

[Daniel Morsing]

Looks good. The skew between tip and release was getting pretty bad in
the final months of go1.1. Hopefully this will help with that.

One thing to keep in mind is that the initial time after a release
will be filled with people sending in changes that they've developed
in private. I don't think there's anything that can be done to stop
it, but it's a thing to keep in mind. An idea would to have a
"golang-next-review" list where people can send their CLs intended for
next release, purely for review.

Regards,
Daniel Morsing

[Maxim Khitrov]

Good plan. Sounds similar to the OpenBSD development model. For anyone
interested, here's a video of Theo explaining how their 6-month
release cycle works:

http://www.youtube.com/watch?v=i7pkyDUX5uM

[Julien Schmidt]

This means there will still be 3 months where no new features can be contributed, right?
Was branching off discussed earlier?

[Mathieu Lonjaret]

Out of curiosity, why the hard "non-negotiable" hard constraint on the dates?

[Andrew Gerrand]

That's correct. The 3 months with no new features is an initially conservative period, which could conceivably be shorter if we feel the tree is stable enough.

I would prefer not to branch, as everyone would then use the dev branch and not give the release candidates the attention they deserve.

Andrew

--

[Andrew Gerrand]

If we are negotiable with the dates then we will find good reasons to go past the deadlines. Hard deadlines will guide our decision-making process for the better, I hope.

[Dmitry Vyukov]

Thanks!

I think the need for a better release process become obvious during
Go1.1 release.

I have a concern about 3 month freeze for changes. I don't know how it
affects others, but I feel that it slowdowns me significantly (delayed
reviews when you already forget what you were doing, large changes
that aggregate lots of small changes on top of each other, etc.).
We should try to minimize freeze time. What about 1 month freeze, and
then the release is branched out, and we do usual backporting of
critical fixes?

Also the freeze will be a good time to improve our testing
infrastructure (e.g. the Brad's stress test). So probably we can relax
freeze rules to account for that.

Also it would be useful to add few sentences for contributors
describing how to better align with the process. E.g. significant
changes must have a design doc and buy in early in the release cycle;
what to do during the freeze, etc.

[Dmitry Vyukov]

I would also like to get this one into:
Compilation failure with -race (fixed)
https://code.google.com/p/go/issues/detail?id=5424

Here are two more compilation failures with -race (not yet fixed):
https://code.google.com/p/go/issues/detail?id=5431
https://code.google.com/p/go/issues/detail?id=5446

I've marked them as Go1.1.1.

[Ian Lance Taylor]

On Sun, May 19, 2013 at 2:20 AM, Dmitry Vyukov <dvy...@google.com> wrote:
>
> I have a concern about 3 month freeze for changes. I don't know how it
> affects others, but I feel that it slowdowns me significantly (delayed
> reviews when you already forget what you were doing, large changes
> that aggregate lots of small changes on top of each other, etc.).
> We should try to minimize freeze time. What about 1 month freeze, and
> then the release is branched out, and we do usual backporting of
> critical fixes?

I simply don't think that is long enough. For 1.1 we spent over a
month finding and fixing obscure runtime bugs. In part that was
because we made a lot of runtime changes. But I don't think we can
say that we can avoid that in the future.

You're right that it will slow down certain kinds of changes. That's
not ideal. But I'm favor of giving this approach a try to see how
difficult it is.

Ian

[Robert Griesemer]

+1.

As Andrew already said, we may change to a 4 to 2 model for the next round. But this is worth a try.

Also, as we are approaching a more mature code base, for the sake of our users we have to move more carefully and deliberately, even if it slows us down.

- gri

[Dmitry Vyukov]

On Mon, May 20, 2013 at 9:14 PM, Ian Lance Taylor <ia...@golang.org> wrote:
> On Sun, May 19, 2013 at 2:20 AM, Dmitry Vyukov <dvy...@google.com> wrote:
>>
>> I have a concern about 3 month freeze for changes. I don't know how it
>> affects others, but I feel that it slowdowns me significantly (delayed
>> reviews when you already forget what you were doing, large changes
>> that aggregate lots of small changes on top of each other, etc.).
>> We should try to minimize freeze time. What about 1 month freeze, and
>> then the release is branched out, and we do usual backporting of
>> critical fixes?
>
> I simply don't think that is long enough. For 1.1 we spent over a
> month finding and fixing obscure runtime bugs. In part that was
> because we made a lot of runtime changes. But I don't think we can
> say that we can avoid that in the future.

Yes, but there were very few obscure runtime bugs and the fixes were
like 1-5 lines. But the time to track them down was very long.
It may be better to backport such changes into release branch, rather
than freeze the development.

[Dmitry Vyukov]

On Mon, May 20, 2013 at 9:19 PM, Dmitry Vyukov <dvy...@google.com> wrote:
> On Mon, May 20, 2013 at 9:14 PM, Ian Lance Taylor <ia...@golang.org> wrote:
>> On Sun, May 19, 2013 at 2:20 AM, Dmitry Vyukov <dvy...@google.com> wrote:
>>>
>>> I have a concern about 3 month freeze for changes. I don't know how it
>>> affects others, but I feel that it slowdowns me significantly (delayed
>>> reviews when you already forget what you were doing, large changes
>>> that aggregate lots of small changes on top of each other, etc.).
>>> We should try to minimize freeze time. What about 1 month freeze, and
>>> then the release is branched out, and we do usual backporting of
>>> critical fixes?
>>
>> I simply don't think that is long enough. For 1.1 we spent over a
>> month finding and fixing obscure runtime bugs. In part that was
>> because we made a lot of runtime changes. But I don't think we can
>> say that we can avoid that in the future.
>
>
> Yes, but there were very few obscure runtime bugs and the fixes were
> like 1-5 lines. But the time to track them down was very long.
> It may be better to backport such changes into release branch, rather
> than freeze the development.

We do not expect lots of changes after a month of freeze. Only
critical fixes must go it, right? In the remaining 2 months we may
have, say, 5 critical fixes. My point is that it's better to backport
5 changes rather than freeze the development for 2 more months.

[Russ Cox]

Why are you arguing against the development freeze? Do you really need a head start making new bugs for the next release?

I'm completely serious. Part of the point of the freeze is exactly to slow everyone down, so that we focus on making the release better and don't get distracted writing code for the next release.  People are of course welcome to write code during that time and not show it to anyone, but alternate mailing lists for "next release CLs" and release branches miss the point. The development freeze is an explicit chance for us to catch our breath and really think about stability, not about new code.

Russ

[Brad Fitzpatrick]

Also, having multiple branches (fun-dev-unstable and stable) means developers and early adopter users are split between the branches, and the stable branch doesn't get as much attention.

[Dmitry Vyukov]

I usually send changes not to introduce new bugs.
The tip will be unstable regardless of when we accept changes, though.

But if it's an intentional freeze rather than process artifact, then
it's a different matter.

[Ian Lance Taylor]

On Mon, May 20, 2013 at 10:22 AM, Dmitry Vyukov <dvy...@google.com> wrote:
>>
>> Yes, but there were very few obscure runtime bugs and the fixes were
>> like 1-5 lines. But the time to track them down was very long.
>> It may be better to backport such changes into release branch, rather
>> than freeze the development.
>
>
> We do not expect lots of changes after a month of freeze. Only
> critical fixes must go it, right? In the remaining 2 months we may
> have, say, 5 critical fixes. My point is that it's better to backport
> 5 changes rather than freeze the development for 2 more months.

We tried this approach in GCC, and the results were clear: once the
release branch was created, all the developers moved on to working on
new development, and nobody worked on stabilizing the release branch.
GCC no longer uses that approach.

Ian

[Robert Griesemer]

I think all of us send changes in the assumption that we are not introducing new bugs... - it's the same as with guns: more of them will lead to more deaths, and it doesn't matter how good the intentions were in the first place.

- gri

[Josh Hoak]

Does the production freeze apply to spin-off libraries (e.g., crypto, net)?

[Julien Schmidt]

There are pros and cons for both options, but in the end it is a decision between development speed and stability.
Let's keep in mind that there is, unlike for most other projects, an API contract for Go.

I think it is better to slow down the development for some time and make sure we made the right decisions.

For example the net.Dialer design was changed after the feature freeze because many people tried the (freezed) development branch and noticed that the first approach didn't satisfy their requirements.

Yes, we would have the same API in the unstable branch, but I think less people would focus and reconsider the changes in the stable branch if all the interesting stuff is happening somewhere else.

Just my two (Euro) cents.

[minux]

On Tue, May 21, 2013 at 1:50 AM, Josh Hoak <jrh...@gmail.com> wrote:

Does the production freeze apply to spin-off libraries (e.g., crypto, net)?

This is a good question. I have general API stability question about those sub-repositories.

I know they are not subject to Go 1 API contract, but does that mean we are free to do

anything and don't need to consider the effect on its users?

for example, is changing import paths or moving packages between sub-repository ok

without some warning/notice on mailing list?

[Ian Lance Taylor]

On Mon, May 20, 2013 at 10:50 AM, Josh Hoak <jrh...@gmail.com> wrote:
> Does the production freeze apply to spin-off libraries (e.g., crypto, net)?

No.

We need a story for those libraries too, but I don't think we know
what it is yet. This proposal is only for the main repository.

Ian

[Kyle Lemons]

The way I see it, we have a maximum of an N month freeze.  The more people who focus on solidifying it, the faster the release can come out, and people can get back to writing new stuff, so in a way it would seem to incentivize all of the right behaviors: putting in CLs that are correct in the first place, closing bugs quickly, and focusing on fixes during the freeze instead of quietly working on new features.

I definitely think this sounds like a great framework for our release process.  I think it'll give customers using Go in production even more confidence than they (hopefully) already have.

[Bruce Fitzsimons]

Looks great to me, but one pedantic terminology note - it's surely not a Release Candidate at the beginning of the freeze?

It's more like a Release Sacrificial Lamb or Beta 1?

I'd expect a significant difference in stability between that release and the next one, assuming we attract enough participation to thrash out the things that the unit tests don't. It's important for the daredevils amongst us to know what the level of risk we're taking on is though.

Also, got any plans to encourage community participation in the stabilisation process? Maybe some of those (2?) Go CI companies could build all the opensource repo's they have with these versions and publish the results?

Cheers,

Bruce

[Dave Cheney]

> Also, got any plans to encourage community participation in the
> stabilisation process? Maybe some of those (2?) Go CI companies could build
> all the opensource repo's they have with these versions and publish the
> results?

While I can't speak for those companies (I hope they will come and
speak for themselves), I think this would be an excellent idea.

During 1.1 Brad setup a camlistore builder to smoke test 1.1, and we
did the same for Juju (and found at least one nasty issue that the
built in tests did not find) so the results of this broad testing
speak for themselves.

Cheers

Dave