> 2c. Reflection is a tradeoff between debuggability and copypasta bugs
> 3. As I said in the issue, it's an unfortunate mistake we weren't specific
> enough but it was permissible and therefore falls under 1a. I generally
> agree with strong typing, and even going forward we should increment ou
>What do you think about just supporting the "major version promise" but
providing a Version number
It doesn't really solve the issue. It still requires users/clients to be
proactive to be correct.
>they would have enough information from the API to decide
That's the heart of it, really: doing t
EDIT:
> I don't think our TO API version should be independent of the TC release
> version
That was supposed to be:
"I think the TO API version should be independent of the TC release version"
On Fri, Apr 19, 2019 at 5:32 PM Rawlin Peters wrote:
>
> 1. Agree
> 2. Removal hasn't really been a p
1. Agree
2. Removal hasn't really been a problem recently, the major concern is addition
2b. Agree, but I could potentially see a lot of the same issues as
minor versioning w.r.t. increased complexity in the codebase to
support PATCH operations
2c. Rob's apiver library seems like a double-edged
@jonathan_gray I generally agree with that list.
>assuming that everyone is ok with ditching minor version support for the
api (not really sure if rob is yet)
I'm ok with ditching minor version support, if we only roll major TC
versions. Which addresses the data loss concerns.
Can anyone explain
sorry, didn't see your summary until after i hit send
On Fri, Apr 19, 2019 at 4:09 PM Gray, Jonathan
wrote:
> Slow down a little bit. Do people believe things in my summary are
> untrue/inaccurate (it's ok if that's the case)?
>
> Jonathan G
>
>
> On 4/19/19, 3:42 PM, "Jeremy Mitchell" wrote:
Slow down a little bit. Do people believe things in my summary are
untrue/inaccurate (it's ok if that's the case)?
Jonathan G
On 4/19/19, 3:42 PM, "Jeremy Mitchell" wrote:
assuming that everyone is ok with ditching minor version support for the
api (not really sure if rob is yet), w
assuming that everyone is ok with ditching minor version support for the
api (not really sure if rob is yet), what about this release plan?
TC 3.0 / supports api 1.3, 1.2, 1.1 (this is already out the door)
TC 4.0 / supports api 1.4, 1.3, 1.2, 1.1 (cut this branch asap)
TC 5.0 / supports api v2, t
Also to be sure I'm tracking properly the complex subject here:
1. Today there are two promises:
1a. One major rev back at the project level for all code/api/etc
1b. API versions independently (but probably not stable enough on whatever
the latest is due to self-discipline/definition)
2. Pr
I'm not sure about the data loss thing. Almost feels like a different
conversation, however, very related. And though I love the idea of pinning
TC=TOAPI versions to each other, they probably don't need to be so I'd
suggest something like this:
TC 4.0
TO API v1 <-- changes were made but NO breaki
How about this:
1. At the Go struct level, every struct for an API endpoint gets a
"Version" field.
2. Every time a backwards-compatible field is added to an API
endpoint, the Version is incremented for that struct (even if a TC
release hasn't been made between increments).
3. This Version field is
I don't really want to always roll major releases. What Jeremy is
proposing is fine with me.
On Fri, Apr 19, 2019 at 1:20 PM Robert Butts wrote:
> @mitchell852 That doesn't address the versioning data loss concerns. What I
> was suggesting would be:
>
> TC 4.0
> TO API v4
> TC 5.0
> TO API v5
>
@mitchell852 That doesn't address the versioning data loss concerns. What I
was suggesting would be:
TC 4.0
TO API v4
TC 5.0
TO API v5
TC 6.0
TO API v6
TC 7.0
TO API v7
So we'd just always roll majors in TC, but otherwise, it's the same. Would
that be ok? Is there an issue with that I'm not seein
I like the idea of pinning the TC and TO API versions together because,
frankly, i like simplicity. And I'm not too worried if we get to version 57
because of it. however, i don't think we will because our api doesn't
change drastically that often. but what about this?
Next version
TC 4.0
TO API
I'm trying really hard to come up with a solution that addresses everyone's
major concerns. I think we'll have a better product, that everyone can live
with, if we all try to think of solutions and are willing to compromise,
rather than take hard-line approach and refuse to compromise, and argue
un
Without actually seeing how that would look across the code base, the
best I can say is maybe. On the surface your proposal seems to improve
the areas I'm concerned about, but we still have this implicit model
where the server is responsible for dealing with older clients that
might not submit all
I really think this is a cost/benefit thing. IMO the cost of supporting the
minor version is just too high. The cost of development, documentation and
testing is very high. Maybe Rob's solution can help with that but I don't
think it will solve the problem of documenting every minor version and
tes
17 matches
Mail list logo
