Hi everyone - I wanted to share some additional information and changes in response to the previous post regarding Connect in Bitbucket Cloud. This second post is a bit long, but the last thing we wanted to do was “under-bake” our response to everyone’s comments.
First, I want to acknowledge everyones input & feedback and thank everyone who contributed. There are several elements that we didn’t communicate effectively, and a few areas where we simply missed the mark and need to make changes.
Most importantly, I want to clarify that this is “the start of a conversation”, not “a final announcement”. We are clarifying some things and making a few changes - so please continue to engage with us, and we will share more information where needed and adjust our plans where appropriate.
There are a few things we’re sharing here:
A change in the timeline for “updates to existing apps”.
Clarity on what exactly is meant by “updates” in this context.
Info on Connect => Forge migration path for Bitbucket apps.
A commitment to “Parity-plus” between Forge and Connect in Bitbucket Cloud.
Our plan & commitment to improve this process moving forward
A quick note on Paid-via-Atlassian
Timeline for “updates to existing apps”:
Initially we stated that, starting in 3-months time, updates to existing Bitbucket Cloud Connect apps in the Marketplace will no longer be possible.
As an immediate change, the timeline for updates to existing apps is being extended to 6 months.
Additionally, any notice period regarding final end-of-support for existing apps will begin no earlier than August 2025, and run for a minimum of 6 months.
Final dates & notice periods will be heavily based on feedback & input from the community.
There is no change to the timeline as it affects new app listings (3 months).
Note “Earliest possible”, may be later based on community feedback
What exactly is meant by “updates” in this context:
We didn’t clearly explain what was meant by “updates to existing apps”, which led to varied interpretations, including the (understandable) assumption that apps could effectively become “frozen”.
So, to be clear on what exactly is meant by “updates”:
Updates that require a change to the scopes defined in an app descriptor.
Updates that require a change to the modules defined in an app descriptor.
Partners will not be prevented from making updates that exist within the already defined scopes/modules of their app descriptors.
e.g content changes to existing UI modules, bug-fixes, etc.
Additionally, exceptions will be made for any updates that are designed to assist the partner in migrating that app to Forge, or assist the partner in migrating their existing users to a Forge-based equivalent.
Unfortunately, we can’t offer the exact same migration path as Jira & Confluence due to differences in the Bitbucket Cloud Connect implementation.
However, there are incremental migration steps available - most importantly, Forge Remote.
This means that your app does not need to be rewritten to run in a node.js environment in order to migrate to Forge.
Regarding migration of existing Marketplace listings & installs - we face a similar situation here.
However, we do want to try and find any opportunities we can to reduce the friction/burden of migrating customers to equivalent apps on Forge.
In line with this, we will commit to publishing an RFC to collect feedback/input from partners on potential ways to streamline this process within the next two weeks.
Additionally, where any specific friction-points are identified in terms of migrating application, we will make sure dedicated support content & guides are created to address those items.
Please let us know of any specific challenges you would like to see addressed.
“Parity-plus” between Forge and Connect:
We are pre-committed to providing parity between Forge and Connect for any feature currently used by more than 5% of Connect Apps.
Any capabilities that fall outside of this are being assessed and prioritised based on partner feedback and needs.
We have also released a range of new features that leverage Forge to provide entirely new capabilities that previously were not possible via Connect, including Custom Merge Checks & Dynamic Pipelines.
If there are any key capabilities currently available in Bitbucket Connect that you feel are not met via Forge, please let us know via the Bitbucket Cloud space in Developer Community or simply commenting below.
While this communication is not a final end-of-support announcement, we strongly recommend that partners begin exploring the migration from Connect to Forge as soon as possible.
We want to ensure the migration to Forge is a success, so we’ll be providing support and resources to facilitate a smooth transition via the Bitbucket Cloud space in Developer Community.
Please continue to post your questions, feedback, issues, etc so that we can identify what needs to be done and support you where needed.
As mentioned, we will publish an RFC in the Bitbucket Cloud space to gather partner input relating to migration friction points for existing app listings within the next two weeks.
Additionally, we’ll be reaching out to the vendors who’s apps account for the overwhelming majority of Connect installations in Bitbucket Cloud directly over the next few weeks to discuss how we can assist in making this transition as smooth as possible.
Paid-via-Atlassian for Bitbucket Apps (PvA):
Speaking personally for a moment, getting this done is particularly important to me.
I know that the lack of PvA is an ongoing point of frustration when it comes to Bitbucket apps.
It’s something I’ve personally said to many of you is coming and that has not changed at all - it’s just a lot of moving pieces.
Significant progress has been made towards this goal and we’re actively implementing the last major platform dependency standing between us and PvA for Bitbucket apps.
We’re not yet at a point where we can give specific dates, but material progress is absolutely being made. We will share timelines with the community the moment we are confident we can commit to them.
Wrapping up
Success for the Bitbucket ecosystem is defined by the success of our partners, and the Bitbucket team is more committed to achieving that today than it ever has been before.
Fundamentally, our goal is to create a consistent, predictable, stable, and “Atlassian standard” extensibility platform that you can all rely on to build your own businesses and serve our shared customers.
Thank you all for your input and for continuing to advocate to make the Bitbucket ecosystem the best it can be. Please share any thoughts, feedback, suggestions, or requests in the comments below.
This is a wish-list item, or another sweet carrot if you will:
bitbucket:repoSettingsMenuPage bitbucket:projectSettingsMenuPage
bitbucket:workspaceSettingsMenuPage
BBC has a project settings page, apps should have too!
Can you also please elaborate what checks are in place on Atlassian’s side, that need to be ticked before the next phase is enforced?
Web Triggers can be used to create your own REST endpoints attached to a Forge app as you can define your own arbitrary HTTP response to be returned from the Web Trigger. The only limitation (that I’m aware of) is that all requests to a Web Trigger must be POST requests, so you can’t do “semantically correct” REST (e.g. POST, GET, etc) - you can absolutely achieve the same functional outcome though.
Profile Tab - Yeah good call, I’m assuming the use-case you’re thinking about is allowing users to create their own “user-specific” settings for apps? What context (other than the details of the user in question + their Workspace) would you want to have available there?
TBH we need to do a full pass of the Project level in regards to Forge, not just settings page. Settings should take priority though since the Project is mostly a configuration container.
In terms of what checks we need to pass before the next phase, my view is that we need to have a clearly documented, “production-ready” way to solve all the existing Connect use-cases before we consider any kind of “next steps”.
Now I do want to be clear, solving all the Connect use-cases does not necessarily mean providing all the exact-same features. API Proxy is an excellent example - I’m hoping there is a way we can solve that “use-case” in a way that is a bit more… conventional. I know it’s basically a meme that “every product includes a non-standardised, undocumented, totally proprietary equivalent of GraphQL” - but API Proxy takes that to a new level.
Would be great to get your feedback re: Web Triggers and whether you see them as a viable equivalent.
@JanNylund - thanks for sharing that! I can’t give you a specific timeline, but we will include this in the list of items that need to be delivered before we enter any next-phase of the process.
Could you share some info in terms of what context you’d like provided from the host app to be passed to that module? I’m assuming:
Repo, Project, Workspace context
Information about the file-path/name
Maybe latest commit hash??
Anything else?
FYI - I will be off on medical leave for the next 2 weeks, but will loop back to this thread when I return. @HamreetKaur will be making sure the mentioned RFC is published before then.
Our app will aim for the “Runs on Altassian” badge. As per the Webtriggers and RoA chat web triggers must not return data if the app has the “RoA” badge. Other vendors have a similar use case.
If “RoA” enforces no data egress, Web triggers is no replacement for any REST API GET or equivalent.
If web-triggers had (optional?) Atlassian authentication though, returning data via web-triggers should not jeopardize “RoA”, because it would just be the same as forge/bridge?
Profile tab
Yes correct. Workzone provides digital signature approvals for PRs. The digital signature tokens are managed in the user’s profile settings page. It’s the best place to give the user a sense of ‘privacy’.
In connect we run on account context with repository scope. Not sure how they map to forge, but essentially we would need:
a filename / extension to trigger the possibility to enable or disable the file viewer (similar to how this works in connect. Preferably also the possiblity to have it enabled by default, as is possible in Bitbucket DC)
read access to the content so we can render it using our custom file viewer.
Thank you all for your valuable feedback! We acknowledge that some comments are still unanswered, and we will be addressing them soon. In the meantime, I’ve just posted the RFC and would love to hear your thoughts on it. Your input will help us align and collaborate effectively on the migration journey. Looking forward to your feedback.
Hi, @EdmundMunday.
Thank you for the open discussion here about the process of migrating Connect apps to Forge. I’d like to share what is essential for us to ensure a successful transition.
Our Connect app currently depends on several modules that don’t yet have equivalents in Forge:
Profile tab – used to display application data at the Workspace level.
Proxy Module – we use this module to enrich requests with contextual data and to verify user permissions when making requests to the application.
Webhooks – Forge currently lacks the events that we use:
repo:transfer
pullrequest:superseded
At the moment, Main Page and Settings Page modules at the project level are not available in either Connect or Forge. Our app could become significantly more useful for users if these modules were introduced in Forge.
Additionally, our app runs background jobs even when users aren’t actively using it. This process requires making API requests to Bitbucket. This functionality is fundamental to our application, and we won’t be able to migrate to Forge without it.
It would also be great to have some way to migrate PvV → PvA.
I’ve provided more details about our application in relation to these requests in my email to you.
We would also need a “Personal Settings Page” e.g. to store user specific credentials.
Very high on our wish-list of extension points would be a module on a Code Insights Annotation. Use-case: show more information and make the annotation actionable. On DC we can show something like this:
I would also be very interested in a “Global page” module which would provide an equivalent to the existing jira:globalPage, confluence:globalPage, and compass:globalPage modules inside Bitbucket Cloud (eg. under an “Apps” section of the home page). It would also implement what the currently nonfunctional “General Page” Connect module describes.
I filed BCLOUD-23558 proposing the new Global page, and BCLOUD-22001 addresses the broken Connect module.
Hey @joshp, @christian.ott, @UlrichKuhnhardtIzym1, @YuriKarnilaevm, @JanNylund - apologies for the delay in getting back to you all here, had some medical issues for a few weeks and have been catching up on everything.
I’m going to respond to all of your questions and comments in the thread under the RFC here so that we can consolidate all the conversations into one place rather than having them spread over multiple threads.
Please keep an eye out for updates in the next few days.
