The CHange is looking good. Thanks @oriser!

I will keep it open for a few days to provide the opportunity for other contributors to review it.
Especially, because this is a breaking change to the existing API (but I think it is a good + manageable one).

Hi, sorry if I'm wrong. Maybe it's a good idea to make a new function along the lines of "GetIssuesForSprintWithOptions", so it would not be a breaking change and possibly add a "MaxResults" option to the options? Then other options, such as "MaxResults" and "StartAt" could also be implemented?

@gueldenstone has a good point. One way this could be done is by something like this

Update the SearchOptions struct to implement the query.Encoder interface from the query package using this method EncodeValues(key string, v *url.Values) error

Then add a new struct type for the JQL string you want added and also implement the query.Encoder interface from the query package using the method EncodeValues(key string, v *url.Values) error

Then update the API for GetIssuesForSprintWithContext so that it looks like this

func (s *SprintService) GetIssuesForSprintWithContext(ctx context.Context, sprintID int, encoders ...query.Encoder) ([]Issue, *Response, error) {
...
url := apiEndpoint
for _, encoder := range encoders {
 url, err := addOptions(url, encoder)
}
...

Since the encoders parameter would be variadic it would not break the API for existing users and allow you to extend the functionality. It would also make it flexible to be able to handle additional encoders in the future.

@benjivesterby I can do it NP, but IMHO it better like the original PR, as I saw the rest of the calls are look like this and I think it better to keep the same conventions..
This breaking change is pretty minor as it will only require to add ,nil to the function call.