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

GitHub API - cannot have differing tag and release names #1723

Closed
csmager opened this issue Oct 26, 2017 · 2 comments
Closed

GitHub API - cannot have differing tag and release names #1723

csmager opened this issue Oct 26, 2017 · 2 comments

Comments

@csmager
Copy link
Contributor

csmager commented Oct 26, 2017

I have a requirement that the GitHub release name is different from the tag. The current API has this signature:

https://github.com/fsharp/FAKE/blob/a133f12f4e5ee9dcc736d2de027f17e99515aa74/src/app/Fake.Api.GitHub/GitHub.fs#L124

The version is used as both the tagName and as the release Name:

https://github.com/fsharp/FAKE/blob/a133f12f4e5ee9dcc736d2de027f17e99515aa74/src/app/Fake.Api.GitHub/GitHub.fs#L109-L110

So I can't currently do this. There are a few ways I can think of to enable it:

  1. Add a new function setName or similar. Not ideal as we're creating with one name and then immediately editing it.
  2. Add a name parameter to createDraft / createRelease functions. This is a breaking change & there are already 7 parameters here.
  3. Add a new function that takes a record of Name, Body, Draft, Prerelease that allows the user to specify exactly what they want for these. This doesn't break anything, though I'm not sure what this function would be named.
  4. Similar to (3), but replacing the existing createDraft / createRelease functions. This is a breaking change.

Happy to submit a PR with changes, but would like some input on an acceptable direction first. I think (3) is probably best.

@matthid
Copy link
Member

matthid commented Oct 26, 2017

If we can think of reasonable defaults for some of the parameters we might even consider to use our regular "Record + override defaults" strategy. I'm fine with breaking changes in this (relatively new) module. Especially since it was never released as stable.

@csmager
Copy link
Contributor Author

csmager commented Oct 26, 2017

OK. If you're happy to break this for FAKE 5 then I'll have a look and create a PR.

I think we can set some reasonable defaults, so will probably go that route for consistency.

  • Name -> tag name
  • Body -> empty
  • Draft -> true
  • Prerelease -> false

Re naming - I can't work out if there's any rhyme or reason for PascalCase vs camelCase. For example, this module is all camel cased but the adjacent Slack module is all pascal cased. Is one preferred? And if pascal case is preferred & I'm making breaking changes, would you like this changed here?

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