github api v2 Feature list

== Proposed

• New implementation will remove bridge methods, deprecated code an so on.
• Side-by-side implementation ** The v2 api will be in a new namespace, leaving the v1 api untouched.
  ** Once v2 reaches feature parity, the v1 api will be deprecated as a whole. ** Where possible the v1 api will become a shim of the v2 api.
• Final objects by default with updatable objects option ** Objects returned from the api will be final by default. ** There will be an updateInPlace(boolean) on GitHubBuilder to make objects non-final. *** If false (default), calls to populate(), refresh(), update(), or set() will return a new instance leaving the original one unmodified. *** If true, calls to populate(), refresh(), update(), or set() will return a the same instance with the updated value.
• Universal use of Builder/Creator/Updater/Setter pattern -
• API more similar to GraphQL even for REST API ** Rather than trying to match the GitHub REST API documentation structure, look at the GraphQL structure. ** Example: instead of gitHub.getRepository("hub4j/github-api") there will be gitHub.repository().nameWithOwner("hub4j/github-api") ** Example: instead of repository.queryPullRequests().state(GHIssueState.CLOSED).list().toList() there will be repository.pullRequests().state(GHIssueState.CLOSED).toList()
• Preview APIs will need to be enabled at the GitHub instance level before use ** Preview APIs will not longer be marked with @Deprecated. This should reduce confusion - we have had multiple users report issues due to thinking that Preview APIs are actually deprecated and should be avoided. ** Preview APIs will need to be enabled at the GitHub instance level. ** If Preview API methods are called without being enabled, they will throw an informative error at runtime. By enabling a Preview the user acknowledges that they may be broken at any time - the project make no guarantees about stability/compatibility for those methods.