The real problem is that the Connect EOL deadline is completely artificial and is under full control of Atlassian and it’s up to Atlassian management to decide whether they want to actually deliver a decent development platform, or if they want to meet their made up deadlines without consideration for the Forge production readiness and maturity. Currently, it seems that Atlassian it focusing on the latter, while trying to plug up as much holes as possible before the deadline.
2 Likes
@rmassaioli what is the extend to which something is considered a Connect / Forge feature parity mismatch within the context of this effort? For instance, the issues raised by @tbinna in Forge platform gaps and new API rate limits are valid blockers for migrating to Forge, especially in combination with API rate limiting, but are not necessarily related to Connect
2 Likes
If you can demonstrate that there is something you can do in Connect, that you can’t do in Forge (even with Forge Remote), and can explain what the consequence of that is for your App/Business, then I would strongly recommend that you follow this process on those FRGE tickets.
We are more than happy to review any issue that any partner feels is a genuine blocker to them.
@tbinna I am already aware of your thread and each of the issues in it, but I would still recommend that you “Request review” if you have not already.
1 Like
Hi @rmassaioli. Our eSignature (connect) app does support and is actively used by customers via the Jira mobile app.
Is there any value in us submitting/escalating FRGE-1492 for consideration? Trying to get a sense if there is an Atlassian decision to not enable Forge on Jira mobile.
Thanks
Chris
Yes. I think that every ticket that you can do in Connect, that you can’t do in Forge (via any means), should be submitted for review.
I think that Mobile App support for Forge Apps qualifies.
Connect framework: In case of site “base_url” change, we used to get install event, Where we could update the base_url of a customer in our database.
Forge framework: In same scenario we don’t get the install event. If we don’t get the base_url then How to identify the changed base_url ?
We have asked the same question on “ECOHELP“, We have received following response
- In connect framework APIs were called using “site base_url“ hence it was important to set the correct base_url.
- In Forge framework it is replaced by cloud_id which never changes.
So now my question is “Is `_edge/tenant_info` API going to remain accessible (without auth) after completely migrating to Forge ?“ so that from base_url we can get “cloud_id“, which is unique.
Finding critical blockers I reported back in 2022 that haven’t been touched.
And again I’ll add that I think it’s lunacy to migrate while versioning is fundamentally broken AND while the AI coding harnesses are improving exponentially every month.
Forcing migration by end of 2026: you’re wasting a stupendous sum of partner time, money and resources for no logical reason. The grunt work of software engineering is very actively being automated but you’re forcing (and penalising) a major mass migration event mere months before full e2e automation.
Rationally setting the migration date to end of 2027: the AI harnesses are extremely good today but I (and most of the software industry) am certain that throughout 2027 we will be able to one-shot migrate any Connect app in a matter of seconds for a few bucks.
That would give partners 12 months to migrate in a reality where you type in “migrate app to Forge” and it does so perfectly regardless of whatever legacy tech debt and Connect-related hacks lurk in your code base. Additionally the AI harnesses will instantly discover parity/blocker issues rather than this repeated and damaging carrot-and-stick approach to crowdsource discovery.
Why waste so much of the ecosystem’s time and resources simply because of mistiming this externality by a matter of months?
1 Like
We are marking the work items important to us according to the process announced here, and it is good to see some transparency going on here.
However, it does seem odd to say the least that migration blockers are only beginning to be collected with a month remaining until the date of the Connect revenue share penalty, and EOL date, and that is after it was pushed back quite a bit. So developers have had to make do with subpar solutions, spend months on figuring out workarounds to things that should not have been an issue to begin with, putting their own plans on hold, to make this arbitrary deadline.
So there is an evident issue of many, many outstanding blockers or at the very least roadblocks, but still the penalty is going to be enforced before, and not after they are addressed.
5 Likes
I can’t request a review because I don’t have a Connect app, but I imagine that the lack of layout customizability is a blocker for many Confluence apps:
Apologies if this has been mentioned before and I missed it:
For FRGE tickets that were requested for review in the first cycle (March), is there a target date when we can expect to learn the outcome of the review (either Approved or Rejected)?
With less than a week to go before financial penalties apply, we are ready to release our Forge version with the exception of one remaining blocker, pending the outcome of the related FRGE ticket review.
If the review ultimately results in a rejection, we will need to instruct our customers to undertake a workaround to ensure that the app continues to operate like our Connect version.
This manual workaround would materially degrade the overall UX of our app, so naturally we want to avoid it if there is a possibility that the review is favourable.
At the same time, we are keen to release our Forge version as soon as possible to avoid financial penalties.
The FRGE ticket in question was original created in August 2024 (so its not a newly discovered issue), and was requested for review on March 12.
Is there a deadline that your team are working towards for every ticket from the March cycle reviewed by?
Any additional timeline information you can provide will assist us in planning our Forge release.
1 Like
For FRGE tickets that were requested for review in the first cycle (March), is there a target date when we can expect to learn the outcome of the review (either Approved or Rejected)?
Our current target is the first week of next month. But since the first month has had a large batch of requests, it is more likely that we release the results of the first month in waives over the next month.
With less than a week to go before financial penalties apply, we are ready to release our Forge version with the exception of one remaining blocker, pending the outcome of the related FRGE ticket review.
If the review ultimately results in a rejection, we will need to instruct our customers to undertake a workaround to ensure that the app continues to operate like our Connect version.
This process will only affect the EOS at the end of the year, it will have no impact on take rate at the end of this month.
Is there a deadline that your team are working towards for every ticket from the March cycle reviewed by?
We plan to answer each request in the month subsequent to when it was requested.