Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nokia Health is now Withings #12

Open
pdbogen opened this issue Mar 27, 2019 · 4 comments
Open

Nokia Health is now Withings #12

pdbogen opened this issue Mar 27, 2019 · 4 comments

Comments

@pdbogen
Copy link
Contributor

pdbogen commented Mar 27, 2019

Hullo!

Not sure how much you want to rename everything, but.. Nokia Health is back to being Withings. Importantly, several URLs have changed and the old URLs no longer work.

I've already opened golang/oauth2#375 to add a golang.org/x/oauth2/withings, and I have a branch that fixes the URLs within the app, renames files, adjusts strings, etc., but.... the package is still nokiahealth.

@pdbogen
Copy link
Contributor Author

pdbogen commented Mar 27, 2019

ah, I guess, there are no new packages in golang/oauth2, so, we'd need to add the relevant oauth config changes to this library I guess.

@jrmycanady
Copy link
Owner

Yeah I have started the process of renaming everything and also updating to match the latest version of the API. I am debating if I should push the changes to a new repo and leave this for legacy or update this repo. Any suggestions would be helpful.

Also ran into packages item on oauth2. Plan to just include the URL in the library.

@pdbogen
Copy link
Contributor Author

pdbogen commented Apr 9, 2019

I can see a few options, and I don't know which you like best. Least work to most work:

  1. Just fix things and don't worry about the repo name. Hurts discoverability.
  2. Rename the repo. Github will redirect humans. People depending on the old name will be SOL, I think, until they update.
  3. Fork the repo, get this one working just enough, with a big old warning message on the README that it's deprecated. Actively maintain only the new one.
  4. Fork the repo, and maintain both. Might be painful due to package paths.

I favor #2 or #3.

@jrmycanady
Copy link
Owner

I am leaning towards 3, primarily because I also want to move to go modules and I feel like that kind of justifies a fork as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants