I knew that is has been put on-hold due to lack of parity between the two versions.
I have not been closely following this topic, but I want to make sure that I did not miss an announcement. I searched on this site and didn’t find anything specific.
No, the resolution to RFC-19 doesn’t say anything about putting the deadline on hold. As of right now, it is the last statement we have from the Confluence Cloud team on the matter.
It seems Atlassian is giving contradictory messages here:
3 Likes
Can you elaborate on where we are contradicting? Tim’s statement didn’t say “put on hold” so it doesn’t defer the deprecation of endpoints for which there are equivalents in v2. And, for those endpoints where gaps are captured, the deprecation is still on a timeline, rather than “on hold”. I’m not clear on where you perceive our disagreement but I would like to close any misunderstanding.
@ibuchanan As I understand it, the contradiction is that Tim stated in his post that v1 APIs “will not be removed from service until 6 months after the v2 API has a suitable replacement,” yet some APIs still don’t have a suitable replacement today, but will be removed from service in three months.
2 Likes
The thing is, Atlassian says the API-v1 endpoints are going to be removed from service quite soon. However the equivalent endpoints in API-v2 have not achieved parity. If I understand @tpettersen correctly, the API-v1 endpoints will be removed from service at the earliest 6 months after having parity, which is at odds with the stated removal of these endpoints really soon.
2 Likes
@klaussner and @marc,
RFC-19 and the resolution assert an “incremental” migration (ie on a per-endpoint basis), not a wholesale deprecation of v1. And, to be clear, the plan has never been to remove all of the v1 endpoints. The most recent information we have is that some endpoints, listed in RFC-19, will be deprecated in 3 months. The exceptions have an open issue in JAC.
I realize the thread on major concerns has multiple developers asserting an “all or none” migration, where all the v2 endpoints must be available (if not also somehow proven stable) before the first endpoint should be removed. But Atlassian, including Tim, have not agreed to that point. Indeed, I read Tim’s statement as a consistent interpretation of RFC-19 and the resolution.
So, I don’t want @eagle.xiao or anyone else confused about what is Atlassian’s stated plan: a piecemeal removal of some v1 endpoints is planned to begin in 3 months.
Hi @ibuchanan ,
The listed APIv1 endpoints will be removed from service in 3 months.
However some of them don’t have full parity in APIv2, and according to @tpettersen , these should be removed from service not earlier than 6 months after achieving parity.
That is the contradiction in Atlassians statements I was referring to.
4 Likes
Hi @ibuchanan
I think one of the gaps in communication stems from this post here, where @tpetterson said about two months ago that the Confluence engineering team has been reviewing the comments and would respond once there were updates. I’ve asked for those updates twice (here and here) but I don’t believe there has been any substantive response.
The gist of the matter is that Atlassian seems to agree that some endpoints don’t yet have parity, but as vendors, we have no idea what these are (from Atlassian’s point of view). Thus, Atlassian may end up deprecating some V.1 endpoints on Jan 31 that are currently marked for deprecation…or maybe all of them…but no one really knows. We also have no idea of the delivery schedule for the missing endpoints. This makes it next to impossible for vendors to effectively plan work, and the clock is ticking.
There is a significant gap in communication here. I suggested two months ago that the following would help:
If there are indeed going to be different deadlines for different endpoints, it gets confusing quickly with information scattered across forum posts. In this eventuality, as @bobbergman1 also suggested, could we please get a spreadsheet or whatever showing, for every endpoint in the V.1 API:
- the projected or confirmed date to sunset that specific endpoint
- the replacement V.2 endpoint(s)
- the ticket(s) on which the work depends, if appropriate, as well as any estimation of delivery dates
I was assuming, perhaps naively, that this was the sort of thing that the Confluence engineering team had taken the past two months to work on. From the vendor perspective, there are still huge blind spots with the migration, as well as missing functionality, and more communication is essential to help us succeed and keep our joint customers happy.
Thanks!
Scott
7 Likes
As a further example, I have an app blocked by CONFCLOUD-76475. (This issue is currently assigned to an Atlassian who appears to have since left the company, which admittedly does not inspire confidence.)
In the meantime, Atlassian seems to have implied that the main GET /rest/api/content/{id} endpoint would not be deprecated until the above CONFCLOUD-76475 issue is delivered, but @tpettersen indicated that we would need to wait on the aforementioned updates in order to find out.
In the meantime, we are just swaying in the wind. Could we found out next week that, no, in fact, it is going to be deprecated anyway according the original schedule, and we now have to scramble to write code to issue thousands of requests to replicate that functionality?
I also added some other issues earlier in the “concerns”, for which I was hoping to see Atlassian responses. I mentioned, for example, rate limits as a potential problem (which is also directly pertinent to the issue above). Another developer has surfaced this as a current problem. And yet rate limits do not appear anywhere in the official ticket queue. I’m unclear about the procedure: should I have filed all of those issues/concerns using the bug submission procedure recommended above? Should I do it now?
6 Likes
One problem that needs fixing, IMO, is using the terms “deprecation” and “removal” in a precise way from this point forward. @tpettersen made this point himself:
From @tpettersen:
Apologies, the language we’ve used here is a little confusing—I’m making a note to be more careful with our terminology. To avoid ambiguity in this context I’m going to use “Deprecated” in the traditional sense of meaning “Marked for removal at some future date”, and “Removed from service” to mean the API is no longer accessible.
Yet even in this thread, the terms continue to be conflated.
We as partners have requested some very clear statements, both on CDAC and in face-to-face meetings with Atlassian, and it was my impression that we were still waiting (more or less) patiently for those statements to be delivered.
Specifically, when will each individual endpoint in the v1 API first be deprecated and then removed. All we have now is what sounds like a likely removal date targeting Jan 31, 2024, for all affected v1 APIs. What we don’t have is a list of exceptions to that removal date based on the known gaps that have either been closed after that announcement was made, or have yet to be closed.
When both @tpettersen and @ibuchanan have stated in the “major concerns” thread that they were working with the Confluence Cloud team to get more information, I took that to mean that we should expect the Confluence Cloud team to:
- provide individual details on specific deprecation and removal timelines for every affected v1 endpoint
- clarify the RFC-19 statements made regarding intended deprecation vs removal
- respond to each of the dozen-ish major concerns raised in the like-titled thread, including for example (but not limited to) the essential problem of how rate limits will be affected by the new increase in traffic resulting from splitting single requests into multiple
The radio silence on all of these problems has been highly aggravating.
7 Likes
First, Ian, I have to sincerely thank you for continuing to engage with us on this, and appreciate your patience in trying to genuinely understand the issues.
Second, I agree that no one from Atlassian has said that the deprecation or removal process itself had been “put on hold” nor did anyone from Atlassian agree to an “all or none” removal.
…it doesn’t defer the deprecation of endpoints for which there are equivalents in v2. And, for those endpoints where gaps are captured, the deprecation is still on a timeline…
What’s ultimately missing here is a simple table of the timeline for each endpoint affected by the presence of a gap. When you say “for those endpoints where gaps are captured…the deprecation is still on a timeline”, it implies that they have (a) been deprecated, and (b) have a removal date identified (which is presumably 6 months from the deprecation date). For those that are still open, this implies that the deprecation clock shouldn’t even be started yet, since the gap still exists. Yet, we keep hearing they are on a timeline but have not been given any dates other than the umbrella “Jan 31, 2024” target. I believe this is the essence of the perceived contradiction.
6 Likes
Thank you for “netting it out” in this thread, and for you patience with us overall. Through your responses here, we have reached some clear and constructive asks for which I can advocate internally.
7 Likes
Thank you @ibuchanan. I appreciate that you continue engage with the community.
For such an important date, I would suggest that it is put on the top in bold font of this page: https://developer.atlassian.com/cloud/confluence/rest/v2/intro/. I am afraid thousands of vendors will receive tickets on the day that the endpoints are removed on 31st Jan 2024.
As many have stated, a list of v1 endpoints that will be removed or kept and pending (if you don’t like the word ‘hold’) is critical. We need to reconcile with the endpoints that we are using and plan for migration. We have already made a mistake by migrating too early.
3 Likes
Another suggestion is that I would assume Atlassian has statistics on the endpoints the apps are using. They can then create tickets for those apps / endpoints to be migrated, similar to the Forge storage migration ticket.
Thankyou, but dude, these asks and concerns were made clear months and months ago.
This is a major migration with major breaking changes, that is extremely likely to have existential business risks for thousands of vendors and millions of customers.
Some of the largest marketplace app vendors have been repeatedly voicing their concerns, with absolute silence from Atlassian.
Mindboggling how poorly the Confluence API team have handled this one.
4 Likes
Hi @ibuchanan
I wanted to check in to see if you had any luck over the last two weeks in getting the attention of the Confluence team. Do you know if some sort of response is to be expected? If so, do you have any guess of roughly when we might hear back?
(As of today, we are sitting at 84 days out from the deprecation date and we still hoping to know the scope of what is being deprecated.)
7 Likes
Hi @ibuchanan
I just wanted to ping again at another +2weeks to see if you had any luck in getting any response whatsoever from the Confluence team. The process feels kinda opaque from a vendor point of view: even if they are not responding, and even if there are no decisions, any information at all you could share would be greatly appreciated (even if it is just to say only that). We are now at only 70 days until the deprecation of…something.
8 Likes
With the update provided in Confluence REST API v2: Update to v1 Deprecation Timeline, I’m going to ask the community to focus on that topic so that we’re all operating on the latest update. Since so much of the community concerns were based on timing, I’m going to close this thread.
Please understand that closure is not an assertion that all questions or problems were addressed. My main concern is that we don’t fragment feedback in too many places, and that it gets to the right people. If there are outstanding questions please ask on the new topic. Or submit a v1-vs-v2 gap to developers support.
2 Likes