I believe we are relying on the downloadable version of the iso in some of our install automation. I'll have to take a look to see.
On Tue, Dec 10, 2019 at 1:47 PM Jeremy Mitchell <[email protected]> wrote: > Yeah, i think changing POST /api/1.1/isos?stream=false to return an error > instead of the expected link would be classified as a breaking api change. > > Also, since we've never written a 2.0 route before, we probably need some > sort of discussion about the approach or simply submit a PR and we can > iterate from there. > > Jeremy > > On Tue, Dec 10, 2019 at 11:25 AM Williams, Adam <[email protected] > > > wrote: > > > To make clear my original proposal – the endpoint would accept and return > > the same JSON structure as the Perl version (v1.1). So in this sense, > it’s > > non-breaking. The difference would be that it would return an error (in > the > > v1.1 response structure) whenever the streaming field is false. I’m not > > sure what the project’s definition or expectations are for API > > compatibility, but wanted to point that out since it’s not obvious to me > > that it’s a breaking change. > > > > I’ll mark the Go version of the route as API version 2.0 (option 3). In > > addition, it can return an error in the case described above. > > > > Thanks for all the help and discussion. > > >
