>How do you feel about that? Would that be simple enough?
possibly. Make a fork and open a Draft PR so we can see it in action. Otherwise
I'm just finding it hard to visualize what the codebase is going to look like
with this library in it.
From: Robert B
>This is about simplifying our code in the API
@jeff.elsloo That's what the tag solution I proposed does. The only
difference from not versioning, is that fields will have a new tag,
"NewField *int `json:"newField, db:"new_field", api:"1.5"`, and endpoints
will have an extra line, "json := api.New
>If you're deploying the head of master, API minor versioning doesn't
really solve that consistent API problem unless we start saying that
every single new field added to an API endpoint is a new minor version
instead of just incrementing an API's version once per TC release.
Yeah, you shouldn't e
On Thu, Apr 18, 2019 at 11:37 AM Robert Butts wrote:
> Something doesn't cease to be an issue, because you redefine it to be the
> user's fault. It's exactly the same issue, removing minor versions just
> makes it much more difficult to debug.
It's not the user's fault, it's the faulty client's f
> Maybe I'm the only one, and everyone else can vote me out, but I don't see
that as acceptable. It's our responsibility as developers to create a safe
user experience, and unacceptable to declare real bugs to be the user's
fault for not using it right. When our Production CDN goes down because an
If you're deploying the head of master, API minor versioning doesn't
really solve that consistent API problem unless we start saying that
every single new field added to an API endpoint is a new minor version
instead of just incrementing an API's version once per TC release.
Even if we do minor ve
That's great! Thank you!
On 4/18/19 1:51 PM, Robert Butts wrote:
When API version 1.3 came out, why could I not call 1.3 for every API
route even if the route didn't change?
That was a Perl mistake, and a bug.
Why not point the 1.3 to the 1.1 for example?
Go does, and we manually do in Per
>When API version 1.3 came out, why could I not call 1.3 for every API
route even if the route didn't change?
That was a Perl mistake, and a bug.
>Why not point the 1.3 to the 1.1 for example?
Go does, and we manually do in Perl now, too.
On Thu, Apr 18, 2019 at 11:47 AM Hank Beatty wrote:
>
+1
I agree with Jonathan but, I ran into my issue going from one TC release
to the next. I want to have the API not break as long as that API is
supported.
I also don't want to have to use multiple versions of the API in my
script unless I absolutely have to for some reason on my end. I wan
>Without minor versions, #3497 would not even an issue. It's only an issue
because of the attempt to support minor versioning.
That's simply not true. It's exactly the same issue. Removing minor
versioning just hides the issue. You have declared:
>only certain clients that don't handle new unknow
At the end of the day, what I want is a consistent API that I can code against
in the head of master that's treated like a contract. As an API user outside
of the ATC repo it's incredibly frustrating to have my stuff break all the
time. It basically encourages never developing using the latest
> The UPDATE statements need modified to fix #3497 even if we get rid of
> versioning. Unless we decide to permanently break all clients older than
> the newest server field, with every new server upgrade. The only other
> option is to fix the updates. Unless you know of a way to fix missing
> fiel
12 matches
Mail list logo
