Create v1.0 tag about tesla HOT 19 CLOSED

I think 1.16 is reasonable. The Go compatibility promise makes this quite safe.

from tesla.

Discussion offline with @michaelharo:

• I'm going to rollback and continue supporting Go 1.13+. He's currently on 1.15 and the changes that are 1.16 only will break him. We can investigate removing ioutil in the future.
• As for the (*Client, error) return type, we're going to keep that for future compatibility in the case that we offer optional args that could cause the client creation to fail.

from tesla.

We should document how to acquire the token file first.

from tesla.

If I have time I'd like to improve the tests and possibly change some data types in the structs before v1.0.

from tesla.

Fine with me.

from tesla.

Could we expose the login stuff as api? My use is integrated with another application, running a separate cmd is not an option. I've basically done the same as here- copied and integrated- but I feel that it really deserves its own auth api?

from tesla.

@andig going to track that here: #22. I don't want to gate tagging v1.0 of a usable API wrapper on that. Hiding both of our comments here.

I've just finished up linting cmd/..., would you be interested in refactoring out the parts you care about to /login and having /cmd/login depend on it?

from tesla.

Some thoughts on the 1.0 release:

• Should the error return for NewClient be removed before 1.0? It can never error and the method signature has changed anyway from jsgoecke.
• I would also suggest to expose the entire oauth2.Config for sake of other users instead of just the Endpoint?
• The go.mod targets go 1.16 which probably isn't necessary if though we might as well replace ioutil.ReadAll with io.ReadAll and the other ioutil functions with their os replacements.

from tesla.

re: oauth2.Config - going to leave that to @michaelharo to think about as he made those changes.

re: go.mod 1.16 - is the suggestion we drop that directive completely? I'll swap out the usage of ioutil in another PR.

from tesla.

@andig I'm using ioutil.ReadFile which is replaced by os.ReadFile doesn't exist <1.16. I'm not clear on the convention of how fast it's expected people would update to 1.16. I'm OK declaring that this library only works in 1.16+ but I'll wait to hear from you and @michaelharo and @uhthomas before I swap out the usages of ioutil.

from tesla.

As long as 1.16 is targeted we can swap the functions. I don‘t think theres any need to require it, could probably be 1.13. I wouldn‘t mind 1.16 as I love the new features even if we don‘t need them here.

from tesla.

#24 as expected, testing <1.16 is broken. I'll remove them from the matrix.

from tesla.

Should BaseURL and StreamingURL be exported? I'm wondering if they should be part of the 1.0 API.

from tesla.

Maybe not exported as a field, but definitely should be settable via functional options. It's essential for black box unit testing, and integration tests.

from tesla.

@michaelharo @uhthomas something like #33?

from tesla.

Yeah, that's what I was thinking.

from tesla.

I will send 2 more small PRs. One rename, one handling token expiry. The latter should go in before 1.0:

• #46
• #47

from tesla.

I just noticed that my change to make struct member names more meaningful is potentially inconsistent. Not sure if we should care...

It uses both DriverFrontDoor and FrontDriverWindow. This was based on the order of the letters in the json struct, but perhaps it Front/Back or Driver/Passenger should always be ordered the same in the names without regard to if it's a Door or Window?

from tesla.

I'm ambivalent to the inconsistency - the inconsistency matches the structure presented by the API. I'm going to tag HEAD as v1.0.

from tesla.