I'm on the fence about dropping 1.4 support. How about waiting until 1.6 is out?

I'm on the fence about dropping 1.4 support. How about waiting until 1.6 is out?

Dunno, what would this support mean? Should we run tests in travis and semaphore with both go 1.4 and 1.5?

Dunno, what would this support mean? Should we run tests in travis and semaphore with both go 1.4 and 1.5?

Basically, yes. For development, our releases, and CoreOS Linux, we'll use 1.5, but we continue providing best-effort support that master builds against 1.4

Basically, yes. For development, our releases, and CoreOS Linux, we'll use 1.5, but we continue providing best-effort support that master builds against 1.4

Uh, that would make semaphore tests from taking ages to complete to taking forever. How about we build rkt with both go versions in travis, but semaphore would build only with 1.5?

OK

On Mon, Dec 21, 2015 at 2:52 PM, Krzesimir Nowak notifications@github.com
wrote:

Basically, yes. For development, our releases, and CoreOS Linux, we'll use
1.5, but we continue providing best-effort support that master builds
against 1.4

Uh, that would make semaphore tests from taking ages to complete to taking
forever. How about we build rkt with both go versions in travis, but
semaphore would build only with 1.5?

—
Reply to this email directly or view it on GitHub
#1907 (comment).

Boo, and I felt so good getting rid of this RKT_XF crap from configure.ac. ;) Alright, will rework it.

sorry, it's my official role as Fun Suppressor™

On Mon, Dec 21, 2015 at 2:59 PM, Krzesimir Nowak notifications@github.com
wrote:

Boo, and I felt so good getting rid of this RKT_XF crap from configure.ac.
;) Alright, will rework it.

—
Reply to this email directly or view it on GitHub
#1907 (comment).

@jonboulle nice one! :)
@krnowak would it be possible to run in parallel 2x semaphore, once per one go version? is it possible?

@krnowak would it be possible to run in parallel 2x semaphore, once per one go version? is it possible?

@jellonek See the discussion above about it - I didn't want to do it on semaphore, because the already long tests would now take forever to complete.

@jellonek The only way to keep times as they are now and run functional tests built with both version of go would be to buy some better plan on semaphore. But it is not up to me to decide about that.

ok, this was what I was asking about, two parallel separate jobs on semaphore.
but if golang 1.6 is planned for the end of January - imo there is no good reason why to do that...

ok, this was what I was asking about, two parallel separate jobs on semaphore.

We already are running two parallel jobs on semaphore - one is building some flavors and the other one the other flavors. We would need to actually have four jobs running in parallel.

The plan is still to move away from semaphore to Jenkins, fwiw.

Krzesimir Nowak notifications@github.com schrieb am Mo., 21. Dez. 2015
18:28:

ok, this was what I was asking about, two parallel separate jobs on
semaphore.

We already are running two parallel jobs on semaphore - one is building
some flavors and the other one the other flavors. We would need to actually
have four jobs running in parallel.

—
Reply to this email directly or view it on GitHub
#1907 (comment).

@krnowak is this good to go?

@jonboulle: Yep. I mean - it is good to be reviewed. :)

LGTM, thank you.