On 5/4/21 6:41 AM, Magnus Hagander wrote:
> On Fri, Apr 30, 2021 at 1:06 PM Sehrope Sarkuni <sehrope@jackdb.com> wrote:
>>
>> On Fri, Apr 30, 2021 at 5:59 AM Magnus Hagander <magnus@hagander.net> wrote:
>>> * I'm thinking the orignal name "latestminor" is actually better than
>>> "minor" -- the previous minor releases still exist after all.
>>
>> I was back and forth on this as well. I figured the endpoint itself represents the latest for each major version so
havingit be "minor" made more sense.
>
> Hehe. I had the same pattern of thinking, but came to the other conclusion :)
>
> Jonathan, want to cast a deciding vote?
Split the difference and do "latestMinor" so it at least follows JSON
convention?
>> A separate endpoint with all historical minor versions could then also
have the same structure.
>
> It could, but we don't actually keep track of historical minor
> versions anywhere at this point. It might be interesting to do so, but
> that's a bigger and separate patch, so let's not get that in the way
> of getting this one approved.
Agreed with Magnus.
>>> * Would it make sense to have an actual query parameter like
>>> "?current=1" or something that would give you *just* the current
>>> version? To avoid having to download all? And maybe also
>>> "?supported=1" to get just supported versions? To avoid having to do
>>> those filterings client side?
>>
>>
>> My own use case would use the full list though I can see both "current" and "supported" being useful as well.
>>
>> If we structure the URL to support that in the future I think that's fine. Rather than query parameters could have
totallyseparate end points:
>>
>> /versions/all.json - Array response with latest of each major version
>> /versions/supported.json - Array response with list of supported versions
>> /versions/current.json - Object response of only current version
>>
>> I don't know which of those would play nicer with how the HTTP caching
works. The expectation is that these endpoints are going to be hit repeatedly by things like CI platforms so we should
getthat part right>
> It should make no practical difference wrt caching. It's still just 3
> URLs -- it would get bad if we supposed a huge mix of combinations,
> but we wouldn't.
I would side with "keep it simple" for the time being, and move forward
with what was originally proposed by this patch (with feedback addressed).
> That said, thinking more about it maybe that's all over engineering
> things. Anybody who's going to want a json file back is going to be
> able to do the parse/filter step easily. So the only real reason to
> separate them would be to reduce bandwidth -- and I can't believe that
> a gzipped (transfer encoding) json file with all our versions is going
> to be big enough to cause any issues..
+1 on the overengineering aspect. It'd be fairly easy to monitor how
much of a bandwidth suck this is (and likely it's little).
Jonathan