Which Jira product are we supporting?

[andygrunwald]

Is your feature request related to a problem?

Jira is available in two different product versions:

• Jira cloud
• Jira server

This project was initially started + used with an on-premise Jira installation (Jira server).
Over time more and more Jira cloud API endpoints landed in this library. See

go-jira/user.go

Line 12 in e1f4265

// JIRA API docs: https://docs.atlassian.com/jira/REST/cloud/#api/2/user

Right now we have the case that we mix the endpoints in this library.
Personally, I don't know

• If the APIs of Jira cloud and Jira server are different / how much they overlap
• how much of the cloud/server endpoints work in the different product version

However, reality is: I am not aware of any issue about the overlapping problem described.

Describe the solution you'd like

The big question to answer:

Which product are we officially supporting/aim to support?

• One? Which one?
• Both? If yes, how? Explicit split? A wild mix like we have now?

Additional question for the cloud product:

• API version 2?
• or/and API version 3? (still in beta)

Additional context

• Jira Server Developer: REST APIs
• Jira Server platform REST API reference (Jira v8.8.1)
• Jira Cloud platform Developer: REST API v2
• Jira Cloud platform Developer: REST API v3 (beta)

[andygrunwald]

@rbriski @ghostsquad @suhaibmujahid Any opinions here?

[ghostsquad]

I think we should support them all, but like other projects, stop supporting old versions. Though in general, this is a bit hard to do properly, since we would likely need a variety of API versions to test against, both cloud and server. @andygrunwald have you reached out to Atlassian about this? Maybe they would sponsor this project and provide us with testing endpoints.

[suhaibmujahid]

In my case, my application interacts with both of the Jira Server and Jira Cloud. To my knowledge, both have almost the same API (see here). They differ mainly in the authentication, which is out of the scope of this package.

Form a usability point of view, a wild mix could be a better option. In this way, the user can interact with both Jira Could and Jira Server without the need to have an extra wrapper layer.

I think it is better to support API version 2 (at least for now) since it is kind of compatible with both Jira Could and Jira Server. If we face inconsistency (if any) we could handle it one by one and document it if needed.

I think it is the user's responsibility to know the expected behavior of Jira itself. On the client-side, it is good if we manage to correctly handle the API calls and having a general enough structs to include all the exposed fields/options.

[mansilladev]

If you're truly looking to support both cloud and server, I suggest making the separation/choice explicit. They're diverging in more ways than just auth. For example, Jira expressions (https://developer.atlassian.com/cloud/jira/platform/jira-expressions/) on the cloud side.. amongst other nuances that could get conflated and confusing as they may continue to diverge.

[ghostsquad]

I agree. This may come at the cost of duplicating some code. Even their documentation is split depending on cloud vs server.

https://developer.atlassian.com/server/jira/platform/rest-apis/

https://developer.atlassian.com/cloud/jira/platform/rest/v3/

In v2 we probably should have cloud/server packages, that potentially call to common code elsewhere, just so that we can support both, but also allow us to make explicit decisions for cloud vs server endpoints/calls.

[ghostsquad]

I'm concerned at our ability to test either though. We don't have a public server that we can run end2end tests against

[andygrunwald]

@ghostsquad
I have reached out to Atlassian about getting an instance sponsored. Seems that this is not possible at the moment. @mansilladev Can you confirm this? Do you see an opportunity to help us here?
This would make the development + testing easier.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 60 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[ChillOrb]

Hello @andygrunwald , I am not able to setup auth and use get user fucntion. Do we have seperate sever package ?

[andygrunwald]

@rishu2403 Can you please create a new issue, provide example code and details on the setup (Jira version, cloud, or on-premise) you are using?

[andygrunwald]

Fixed in #492