Warnings? Errors? When updating the whole stack today

[Roger Peppe]

On Tue, Jun 11, 2013 at 7:49 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ...
>>> We won't be able to get go 1.1.1 backported to precise, so if we
>>> want to use the builders to make the juju client binaries that we
>>> backport to precise, we need to use go 1.0.3.
>>>
>>> For binaries on Saucy (and what we upload) we can feel free to
>>> use go 1.1.1, but we should stay compatible with 1.0.3.
>>
>> So we can't start using Go 1.1.1 until 2017?
>
> There is a difference between using it when available, and requiring
> it always.
>
>>
>> I do hope that's not the case. There are many bugs fixed in 1.1.
>> We'll also need to make our own forks of external dependencies such
>> as go.crypto and keep them up to date, which will involve some
>> resources on our side.
>>
>
> We can use 1.1.1 when available and get all of those bugfixes. (As
> stated before, we should do official builds as much as possible with
> 1.1.1).

It's a pity that the Precise version that almost everyone will be
using all the time won't be built with it.

> That doesn't mean we should use 1.1+ only features. So far there are a
> couple of nice-to-haves but nothing that is particularly critical.
> (not having to wrap methods in closures, and having to write panic()
> or return at the end of functions.)

Actually there's at least one new feature in the reflect package
that I'm about to make a sordid hack to get around the lack thereof
(reflect.SliceOf) and would very much like to be able to use.

> The way most systems go about this is to have stable releases that
> target stable environments (eg LTS releases of Ubuntu), and then get
> only bug and security fixes, without any major feature changes.
>
> I don't think juju 1.10 is enough for Precise to become a stable
> series. My personal proposal would be:
>
> 1) Get to a point where we can do Major Version Upgrades (stable API
> everywhere, and upgrade logic)
>
> 2) Release that as 2.0, and keep that compatible with go 1.0.3
>
> 3) Backport juju-core 2.0 to all appropriate releases, get it
> available to people running those platforms.
>
> 4) Maintain a stable series of bugfixes on that as appropriate.
>
> 5) For the next LTS (14.04) we can switch to requiring go >=1.1 and
> have a new stable release of Juju. So there will be some bugfixes that
> might have to land for the 2.0 series that is available on precise,
> but most focus will be on the 3.0+ series that is on 14.04.
>
> Where possible, we can provide a PPA/etc of the new juju for Precise
> built with a 1.1 Go compiler.
>
> So we aren't stuck with go 1.0.3 compatibility forever, probably just
> for about 6 more months (since we can be developing against 14.04 once
> 13.10 opens up), but we would maintain *a* branch that is 1.0.3
> compatible for longer.

That seems possible. So should we import all our go.* external
dependencies into juju-core
now, so that things won't break when they inevitably change to use go
1.1 features?

These are our current external dependencies:

code.google.com/p/go.crypto/cast5
code.google.com/p/go.crypto/openpgp
code.google.com/p/go.crypto/openpgp/armor
code.google.com/p/go.crypto/openpgp/clearsign
code.google.com/p/go.crypto/openpgp/elgamal
code.google.com/p/go.crypto/openpgp/errors
code.google.com/p/go.crypto/openpgp/packet
code.google.com/p/go.crypto/openpgp/s2k
code.google.com/p/go.net/websocket

Another possibility that's probably a really stupid idea
but maybe worth mentioning: we could include the
go compiler as part of the package that's built on Precise.
It's 70MB - perhaps not entirely out of the ballpark.
That would save a lot of hassle.

  cheers,
    rog.