+1 on 3. I thought there were some changes made in 1.10 that have the
possibility of breaking things, i.e. I think it breaks some of Grove. They may
or may not affect TC but who knows what might happen in the future. So I would
think you would want the version pinned
I vote for option 3 since the version of go you compile with is no different
than the version of a library used in the build process. By specifying what
version it shall be, we also know when we go to newer versions and have more
reproducible builds.
On 6/7/18, 3:27 PM, "Dan Kirkwood" wrote:
I vote on option 1.
Steve
On Thu, Jun 7, 2018 at 5:27 PM Dan Kirkwood wrote:
> Hey, all.. I just investigated this issue (
> https://github.com/apache/incubator-trafficcontrol/issues/2380) and
> realized that the `go` version being used in building traffic_stats and
> traffic_monitor is diff
Hey, all.. I just investigated this issue (
https://github.com/apache/incubator-trafficcontrol/issues/2380) and
realized that the `go` version being used in building traffic_stats and
traffic_monitor is different from that of traffic_ops due to the way it's
installed during the rpmbuild phase.
+1, this will allow us to do a better job with the API's
On Tue, Jun 5, 2018 at 10:03 AM Jeff Elsloo wrote:
> In light of the major changes introduced into Traffic Router with PR
> 2331, I would like to call a vote to increase the major version of the
> project to 3.0.0. Also note that this vers
Waiting on making these breaking changes will also give us an opportunity to
step back and make holistic design decisions in regards to the new api spec as
a community.
On 6/7/18, 11:47 AM, "Robert Butts" wrote:
>Does this also present an opportunity to do some breaking API changes for
>Does this also present an opportunity to do some breaking API changes for
Traffic Ops that we’ve been wanting to do?
@jvd Technically yes, but I'd vote we don't, because it's going to add a
lot more work to Self-Service to try to port APIs, maintain two major API
versions for at least a major rel
We need to give our users some short-lived guarantee about backwards
compatibility because it is necessary for upgrade.
Can we agree
“All Traffic Control 2.y components will work with a Traffic Ops 3.0”
with the following constraints:
- 2.y is the last release in the 2.x train
- 3.0 i
+1
Does this also present an opportunity to do some breaking API changes for
Traffic Ops that we’ve been wanting to do?
Cheers,
JvD
> On Jun 7, 2018, at 10:10 AM, Volz, Dylan wrote:
>
> +1
>
> On 6/7/18, 8:52 AM, "Robert Butts" wrote:
>
>+1 Dropping support is breaking change, and n
Traffic Router 3.0 works with all of the 2.x components regardless of which OS
they are on, but TR must be on Centos 7. If you already have a 2.x version of
TR on Centos 7 then 'yum update traffic_router' will clean up the old version
leaving only the logs and the .properties files. It will als
+1
On 6/7/18, 8:52 AM, "Robert Butts" wrote:
+1 Dropping support is breaking change, and needs a major version
increment, per Semantic Versioning.
On Tue, Jun 5, 2018 at 10:03 AM, Jeff Elsloo wrote:
> In light of the major changes introduced into Traffic Router with P
Since we are increasing the major version, I would assume that 2.x
components will not work with 3.x components. The reality may be that they
do work together, but I wouldn't count on it.
In addition to what was mentioned above I think that we should including
deprecating support for the Traffic
For those of us already on Centos7, what does this mean for compatibility
between TC releases?
On Centos7, will we be able to use 3.0 with 2.x releases as is currently done
today.
If already on Centos7, What is the upgrade story from 2.2 to 3.0?
—Eric
> On Jun 5, 2018, at 12:03 PM, Jeff Elsl
+1 Dropping support is breaking change, and needs a major version
increment, per Semantic Versioning.
On Tue, Jun 5, 2018 at 10:03 AM, Jeff Elsloo wrote:
> In light of the major changes introduced into Traffic Router with PR
> 2331, I would like to call a vote to increase the major version of th
Thanks to all who voted!
The release has PASSED with the following IPMC votes:
+1 Jeff Elsloo (binding)
+1 Steve Malenfant (binding)
+1 Dan Kirkwood (binding)
I will proceed to publish the release and send ANNOUNCE.
On behalf of Apache Traffic Control, thank you!
Regards,
Robert O Butts r...@a
Rawlin,
Yes, I am using a version which Eric referred to (i.e) Cisco's version. And
looks like in this code it is actually possible to create MSO groups
(origin server) which may not contain the org_serv_fqdn. So do you think,
MSO enabling and Go Direct = True as mutually exclusive will work?
Tha
16 matches
Mail list logo
