Bitbucket Server upgrade guide

This page describes how to update your Bitbucket Server installation to the latest version. We strongly recommend that you update Bitbucket Server by performing the steps below. Note that:

  • This update process does not perform an in-place upgrade, but installs the new version of Bitbucket Server into a fresh installation directory. The new instance uses your existing Bitbucket Server home directory and external database.
  • For production environments, we recommend that you test the Bitbucket Server update on a staging server before deploying to production.
  • You can update from any previous version of Stash to the latest version of Bitbucket Server. There is no required established upgrade path.
  • Upgrading from Stash to Bitbucket Server disables all user-installed add-ons. Be sure to update your own add-ons and check the Atlassian Marketplace to ensure 3rd-party add-ons are compatible with Bitbucket Server before upgrading. Read more about this change.
  • If necessary, rolling back an update can only be performed by restoring a backup of both the Bitbucket Server home directory and the Bitbucket Server database – rolling back requires a consistent home directory and database. You can then reinstall the previous version of the application to the installation directory. Read the Rollback section for more details.

1. Review the upgrade notes

There are specific upgrade notes further down this page for each version of Bitbucket Server. You should read the relevant sections for each version between your current version and the version you are upgrading to. Note that you can update from any previous version to the latest version of Bitbucket Server.

2. Back up your data

Before proceeding any further you must take a backup of all your data in the Bitbucket home directory first. This is important as it will allow you to return to a known starting point if you encounter trouble for any reason during the upgrade process.

For Bitbucket Server (version 4.8 or later) instances, you can use Zero Downtime Backup, the Backup Client (version 2.7 or later ), or  DIY Backup (version 2.12 or later) while Bitbucket is running, or just stop Bitbucket and zip up / snapshot the home directory and database and keep them somewhere safe.

For Bitbucket Data Center (version 4.8 or later) instances, you can use Zero Downtime BackupDIY Backup, or take snapshots of the shared home directory (on NFS) and database while all nodes are stopped. 

For Bitbucket mirrors, the home directory doesn't really store any persistent state that can't be reconstructed from the primary Bitbucket instance, but you should still make sure you have a backup of at least the important configuration files such as SSL certificate, server.xml config/ssh-server-keys.pem bitbucket.properties file, and so on in a safe place. See  How do I back up my mirrors?  for more information.

See the article Data recovery and backups for more detailed information and guidance on creating an effective backup strategy.

3. Stop the application

See Starting and stopping Bitbucket Server for detailed instructions. 

For Bitbucket Data Center, stop all nodes of Bitbucket Data Center, perform the steps to upgrade for a single node first, then repeat the process on each cluster node.

4. Install Bitbucket Server

This update process does not perform an in-place upgrade, but installs the new version of Bitbucket Server into a fresh installation directory. The new Bitbucket Server uses your existing home directory and external database. Check that you have all the system requirements for the new version of Bitbucket Server, including Perl, to avoid any trouble. See also the End of support announcements for Bitbucket Server. You can install Bitbucket Server by either:

For Bitbucket Data Center instances, repeat the update process for every cluster node. 

Use the Bitbucket Server installer to update your installation (Recommended)

You can run the installer in GUI, console or unattended modes. On Linux, you need to set the executable flag on the installer file before running it: 

chmod +x atlassian-bitbucket-x.x.x-x64.bin

To upgrade using the installer

  1. Download the Bitbucket Server installer
  2. Open and run the installer. 
  3. At the 'Welcome' step, choose the Upgrade an existing Bitbucket instance option.
    For a Bitbucket mirror, choose the Upgrade an existing mirror option.
  4. At the 'Select Bitbucket Server Home' step, browse to your existing home directory.
    (as defined by the BITBUCKET_HOME environment variable – see Bitbucket Server home directory):

      If upgrading from Stash 3.4 or earlier...

    Stash 3.5 and later versions no longer allow the  Bitbucket Server home directory  to be the same directory as, or a subdirectory of, the Stash installation directory. The Stash home directory, as defined by the  STASH_HOME  environment variable, must be in a separate location – otherwise Stash will fail on startup.  If upgrading from a previous version of Stash where the Stash home directory is owned by a local user, the ownership of all files will be updated to atlstash . Please allow sufficient time for the installer to complete this process (it could take up to 30 minutes).

  5. Proceed with the remaining installer steps.

Use an archive file to update your Bitbucket Server installation

Only use an archive file to update Bitbucket Server if the installer is not suitable for your situation. The installer is the the recommended approach to upgrade for most use cases.

Follow the instructions at Upgrade Bitbucket Server from an archive file. Note that on Windows, Bitbucket Server 3.5 and later versions will refuse to start if the installation path contains spaces when Bitbucket Server is installed from an archive file. The installer prevents you from creating such a path.

Change dedicated user account from 'atlstash' to 'atlbitbucket'

When upgrading from Stash 3.x or older to Bitbucket 4.x or later, the installer provides an option to remove the atlstash dedicated user account and replaces it with a user account named atlbitbucket. If you are installing Bitbucket Server using an archive file you must create the atlbitbucket user account for Bitbucket Server to work properly. Read more about creating this dedicated user account

5. Update server.xml (upgrading from Stash 3.7 or earlier)

If you are upgrading from Stash 3.8 or later you can skip to step 6, Start the application, below.  If you are upgrading from Stash 3.7 or earlier and you have made  custom changes  to the server.xml file in your installation, you have to make those changes in the server.xml file of your new installation as well, which is in a different location as of Stash 3.8.  You would have made these changes if you modified the portcontext path, or the access protocol, or if you are running Bitbucket Server behind a proxy and modified the Connector element. 

Locating the server.xml file

The location of the server.xml file changed in Stash 3.8 to keep editable configuration files in the Bitbucket home directory and out of the (version specific) installation directories. 

Release Directory 
Stash 3.7 and earlier <Stash installation directory>/ conf/server.xml
Stash 3.8 and later <Stash home directory> /shared/server.xml
Bitbucket Server 4.0 and later <Bitbucket home directory> /shared/server.xml

Applying your customizations

The default content of server.xml was not always identical in past versions of Bitbucket Server (or Stash). Rather than just copying server.xml from your existing <Bitbucket installation directory>/conf to <Bitbucket home directory>/shared of your latest Bitbucket Server instance, you should carefully review the differences between your customized version and the default version and re-apply just your custom changes to the new server.xml file. Once you have applied your custom changes in  <Bitbucket home directory>/shared/server.xml, you will not need to perform this step again in future upgrades. 

Custom configurations in Bitbucket Data Center

For Bitbucket Data Center, using Stash 3.8 or later, the single server.xml file in the <Bitbucket home directory> /shared directory replaces all the copies of server.xml located in the  <Bitbucket installation directory>/conf directories of the cluster nodes using previous versions of Bitbucket Server (or Stash).

6. Start the application

If you installed Bitbucket Server using the installer, there is an option to start the application. If you installed Bitbucket Server manually from an archive file then see Starting and stopping Bitbucket ServerFor Bitbucket Data Center instances, repeat the process on every cluster node. Either way, note that the database schema migration task that runs when Bitbucket Server is started after an update can take a while, especially if the update skipped a few releases (for example, upgrading from 2.2 to 2.7). Bitbucket Server should never be interrupted while this is happening, even if it appears to hang for a bit – allow the server to either come up, or fail to come up (when it will provide an explanation of what went wrong).

 

Rollback

If necessary, rolling back an update can only be performed by restoring a backup of both the Bitbucket Server home directory and the Bitbucket Server database – rolling back requires a consistent home directory and database. You can then reinstall the previous version of the application to the installation directory. Never start an older binary against an upgraded home directory.


Version-specific update notes

This section provides specific update notes for each version of Bitbucket Server (previously known as Stash). These notes supplement the primary upgrade instructions above. You should read the relevant sections for each version between your current version of the application and the version you are upgrading to.

Bitbucket Server 4.12 update notes

You should also see:

 

Do NOT upgrade to Git 2.11+

Any version after Git 2.11.0 (including future 2.12+ releases) cannot be used with Bitbucket Server. Bitbucket Server 4.12 will fail on startup if Git 2.11+ is detected. Only upgrade to versions of Git which are explicitly marked supported on our Supported Platforms page.

BSERV-9388 - Pre-receive hooks and branch permissions reject valid pushes on git 2.11 Closed

 

Known issues

Bitbucket Server 4.0 update notes

Please also see:

Do you rely on user-installed add-ons?

Your plugins may not be compatible with Bitbucket Server 4.0 (yet)

Upgrading from Stash to Bitbucket Server will disable all user-installed add-ons, whether they are 3rd-party add-ons from Atlassian Marketplace, or your own custom add-ons. User-installed add-ons will need to be checked, upgraded and enabled again once you've finished the upgrade process. You should check the marketplace listing for 3rd-party add-ons to determine if there is a release that is compatible with Bitbucket Server 4.0. Unless they have been updated to work with Bitbucket Server 4.0, existing add-ons (or plugins) that use the API interfaces that have been removed in Bitbucket Server 4.0 will not work. Similarly, custom add-ons need to be upgraded for Bitbucket Server compatibility. See the documentation on how to update your add-on for details.

If you are upgrading from Stash 3.x to Bitbucket Server 4.x, you should be aware that most user-installed add-ons will be incompatible with Bitbucket Server 4.0. After upgrading, go to Admin > Manage add-ons, look for messages of this form, and follow the advice to update:

If no newer version is available the add-on will remain disabled. 

New dedicated user account 'atlbitbucket'

A new dedicated user account will be created to run Bitbucket Server, called atlbitbucket. During the upgrade process, you will have an option to delete the dedicated user account for running Stash, named atlstash. For most users, deleting this dedicated user account won't have any negative consequences, however if you rely on this dedicated user accounts, for example in custom backup scripts, you will need to update the user account in those scripts.

Updates to logger names

If you have customized your logging configuration by manually editing the logback.xml file (using steps found in the Configure Stash Logging KB article), you should be aware of changes to several logger names that may require you to update some of your configuration files.

  See the logger name changes...
Stash logger name Bitbucket Server logger name 
stash.application bitbucket.application
stash.profiler bitbucket.profiler
stash.access-log bitbucket.access-log
stash.audit-log bitbucket.audit-log
stash.mail-log bitbucket.mail-log

Important security improvement which may require configuration changes

Previous to Bitbucket Server 4.0, a security constraint for redirecting from HTTP to HTTPS was not enforced, meaning users could type "http://<bitbucketserver-url>" into their browser and still be shown a functioning version of Bitbucket Server (or Stash). Included with the release of Bitbucket Server 4.0 was a fix to enforce that security constraint. Using the previous security configuration with Bitbucket Server 4.0 means trying to access the application over an insecure connection, when users type "http" when trying to get to the application, they could encounter erroneous behavior. 

As part of upgrading from Stash to Bitbucket Server, it is recommended you update your security configuration in order to avoid encountering this problem. See this Knowledge Base article for more information and specific instructions on addressing this: Redirect HTTP Requests to HTTPS.

Known issues

Stash 3.11 update notes

Please also see:

Known issues

Loading
P Key Summary Status

Stash 3.10 update notes

Please also see:

Are you using Git 2.2x - 2.4.0?

Git 2.2.x - 2.4.0 have reported performance issues when interacting with NFS. Hence, these versions are currently not supported for Stash Data Center or for Stash Server installations that use NFS mounts for the home directory.

Known issues

Stash 3.9 update notes

Please also see:

Are you using JIRA as a Crowd server?

Stash 3.9 cannot use JIRA 6.4 as a Crowd server due to a bug in JIRA 6.4.  Please upgrade to JIRA 6.4.1 before upgrading Stash. (Note that Stash 3.7.2 and 3.8.0 contained a workaround for the bug but the workaround was removed in Stash 3.9)

Known issues

Loading
P Key Summary Status

Stash 3.8 update notes

Please also see:

Have you made customizations to Tomcat's server.xml file?

For Stash 3.8 (and future versions) the server.xml file is now located in the <stash home directory>/shared directory. The benefit of this move is that your customizations to server.xml (such as those described in step 5) will not have to be redone for future upgrades.

(warning) You do still need to update your custom configurations in shared/server.xml  for the upgrade to Stash 3.8, as described in step 5.

Deprecation of HighlightJS for syntax highlighting

The highlighting engine was changed in Stash 3.5 from HighlightJS to CodeMirror. The use of HighlightJS for syntax highlighting in Stash is now deprecated, and will be removed in Stash 4.0. See Syntax highlight changes for information about how to migrate any custom mappings for HighlightJS that you may have made.

Known issues

Stash 3.7 update notes

Please also see:

Do you use JIRA 6.4?

JIRA 6.4 has a known issue with Stash versions 3.4.3 to 3.7.1, which prevents the user synchronization from working. This will only affect you if you use JIRA to manage your users in Stash, and is fixed in Stash 3.7.2.

Deprecation of HighlightJS for syntax highlighting

The highlighting engine was changed in Stash 3.5 from HighlightJS to CodeMirror. The use of HighlightJS for syntax highlighting in Stash is now deprecated, and will be removed in Stash 4.0. See Syntax highlight changes for information about how to migrate any custom mappings for HighlightJS that you may have made.

Known issues

Loading
P Key Summary Status

Stash 3.6 update notes

Please also see:

Secure email notifications

Stash 3.6 now:

  • Allows you to require STARTTLS support on the mail server when using SMTP – if it is not supported, mail is not sent. 
  • Supports SMTPS (where the whole protocol conversation uses SSL/TLS).

See Setting up your mail server for more information.

Note that if you use either SMTP with STARTTLS or SMTPS and connect to a self-signed mail server you may need to import the server's certificate and set up a custom cacerts file for Stash (just as you do for any outbound SSL/TLS connection to a self-signed server). See this  Stash knowledge base article for information about how to do that.

Deprecation of HighlightJS for syntax highlighting

The highlighting engine was changed in Stash 3.5 from HighlightJS to CodeMirror. The use of HighlightJS for syntax highlighting in Stash is now deprecated, and will be removed in Stash 4.0. See Syntax highlight changes for information about how to migrate any custom mappings for HighlightJS that you may have made.

Known issues

Stash 3.5 update notes

Please also see:

Stash home directory location

Stash 3.5 and later versions no longer allow the Bitbucket Server home directory to be the same directory as, or a subdirectory of, the Stash installation directory. The Stash home directory, as defined by the STASH_HOME environment variable, must be in a separate location – Stash will fail on startup otherwise.

Deprecation of HighlightJS for syntax highlighting

The highlighting engine in Stash has been changed from HighlightJS to CodeMirror. The use of HighlightJS for syntax highlighting in Stash is now deprecated, and will be removed in Stash 4.0. See Syntax highlight changes for information about how to migrate any custom mappings for HighlightJS that you may have made.

Known issues

priority key summary status

JIRA project doesn't exist or you don't have permission to view it.

View these issues in JIRA

Stash 3.4 update notes

Please also see:

Changed group membership aggregation with multiple user directories

Stash 3.4 uses new schemes to determine the effective group memberships when Stash is connected to multiple user directories, and duplicate user names and group names are used across those directories. The new schemes are: 

  • 'aggregating membership'
  • 'non-aggregating membership'.

These group membership schemes are only used to determine authorization. Authentication is determined on the basis of the group mappings in each directory.

See Effective memberships with multiple directories in the Crowd documentation for more information.

When you update to Stash 3.4, an update task will apply one of those schemes as follows:

Aggregating membership will be applied to your instance:

    • If there is only one active directory.
    • If there are multiple active directories but only a single directory applies group memberships to any particular user.
    • For example, if directory-1 contains user-a in group-x, and directory-2 contains user-b in group-y, then Stash 3.4 will apply aggregating membership, and permissions will not be affected.

Non-aggregating membership will be applied to your instance:

    • If there are multiple active directories and more than one directory applies group memberships to at least one user.
    • For example, if directory-1 contains user-a in group-x, and directory-2 contains user-a in group-y, then Stash 3.4 will apply non-aggregating membership. If group-y has admin provileges then user-a would have their privileges escalated in this case if aggregating membership was applied instead when upgrading to Stash 3.4.

Any changes made by the update task will be logged.

A Stash admin can change the membership scheme used by Stash using the following commands:

  • To change to aggregating membership, substitute your own values for <username><password> and <base-url> in this command:

    curl -H 'Content-type: application/json' -X PUT -d '{"membershipAggregationEnabled":true}' -u <username>:<password> <base-url>/rest/crowd/latest/application 
  • To change to non-aggregating membership, substitute your own values for <username><password> and <base-url> in this command:

    curl -H 'Content-type: application/json' -X PUT -d '{"membershipAggregationEnabled":false}' -u <username>:<password> <base-url>/rest/crowd/latest/application 

 

Please note that changing the aggregation scheme can affect the authorization permissions for your Stash users, and how update operations are performed. Read more about using Stash with multiple use directories.

Known issues

Stash 3.3 update notes

Please also see:

Known issues

Loading
P Key Summary Status

Stash 3.2 update notes

Upgrading to Stash 3.2 or later from Stash 3.1 or earlier is irreversible – please see the Home directory migration section below.

Please also see:

Note that:

Home directory migration

When you update to Stash 3.2 or later, an update task migrates directories in your Stash home directory to new locations. This is irreversible – once you update to Stash 3.2 or later you can not revert to Stash 3.1 or earlier, because of changes to the Stash home directory format.

For most installations, Stash 3.2 is able to perform these moves automatically and transparently. However, in the rare instance where Stash 3.2 can't perform the update automatically, please refer to Upgrading your Stash home directory for Stash 3.2 manually.

Undocumented home directory overrides are no longer supported

Before Stash 3.2 it was possible to override the location of the following subfolders in the Stash home directory, using undocumented environment variables or system properties:

  • export
  • bin
  • caches
  • config
  • data
  • lib
  • lib/native
  • log
  • plugins
  • tmp

In Stash 3.2 only the  tmp  subfolder can be overridden in this way. Attempting to override the others will fail on startup. For more information, please see  Stash fails to start - UnsupportedDirectoryOverrideException

Stash analytics

Stash 3.2, and later, collects user event data, unless this is disabled by an administrator. You will see outgoing network traffic to amazonaws.com. See Collecting analytics for Bitbucket Server.

Known issues

Stash 3.1 update notes

Please also see:

Note that:

Known issues

Loading
P Key Summary Status

Stash 3.0 update notes

Stash no longer supports Java 6

Stash 3.0 requires at least Java 7, and supports Java 8.

Please see the End of support announcements for Bitbucket Server.

Your plugins may not be compatible with Stash 3.0

The interfaces in the Stash API for plugin developers that were deprecated in Stash 2.11 and earlier have been removed in Stash 3.0. This means that, unless they have been updated to work with Stash 3.0, existing Stash add-ons (or plugins) that use these interfaces will not work with Stash 3.0.

Please see the section below about Stash add-on incompatibilities for more details.

Please also see:

Note that:

Stash add-on incompatibilities

Unless they have been updated to work with Stash 3.0, existing Stash add-ons (or plugins) that use the API interfaces that have been removed in Stash 3.0 will not work.

Fresh installs of Stash 3.0 shouldn't encounter any problems. The Stash 'Manage add-ons' page (in the admin area) should only display add-ons from the Marketplace that have been marked as compatible with Stash 3.0. Incompatible add-ons won't be available in the list. 

However, if you are upgrading from Stash 2.x to Stash 3.0, you should be aware that some existing installed add-ons may be incompatible with Stash 3.0. After upgrading, you should go to Admin > Manage add-ons, look for messages of this form, and follow the advice to update:

If no newer version is available, the add-on must be disabled. 

Custom add-ons

Please note that your custom locally-developed plugins may be affected by the API removals in Stash 3.0. You will need to update your custom plugins if you want those to work with Stash 3.0. See the Stash API changelog for details of the deprecated APIs.

Third-party add-ons

You'll need to check on Atlassian Marketplace for the compatibility status of any 3rd-party add-ons that you use.

Third-party add-on developers have been given an Early Access Program (EAP) build of Stash 3.0 in advance of release, and many have already updated their add-ons to be compatible. Add-ons must be explicitly marked by the publisher as compatible with Stash 3.0 for them to appear in 'Manage add-ons' page in Stash. This is NOT automatic as was the case with previous minor releases such as 2.10 and 2.11. Atlassian can not support issues involving third party Add-ons that are incompatible with Stash 3.0; such support cases must be directed to the third-party publisher of the add-on. See Managing add-ons.

Atlassian add-ons

All of the Atlassian add-ons for Stash that are available from the Atlassian Marketplace have been updated to be compatible with Stash 3.0. If you use any of these in your Stash installation you'll need to update them to the Stash 3.0 compatible version.

Add-on JAR file name Stash 3.0 compatible version
Custom Navigation Plugin custom-navigation-plugin 2.0.3

Stash Archive Plugin

stash-archive 1.3.0
Repository git operations plugin stash-git-ops-plugin 1.2.1
Stash Auto Unapprove Plugin stash-auto-unapprove-plugin

1.1

Stash Protect Unmerged Branch Hook stash-protect-unmerged-branch-hook 1.1
Stash Reviewer Suggester stash-suggest-reviewers 1.2
Stash Web Post Hooks Plugin stash-web-post-receive-hooks-plugin 1.1.0
Realtime Editor for Stash stash-editor-plugin 1.0.6

Known issues

Stash 2.12 update notes

Please also see:

Note that:

  • Stash does not yet support Java 8.
  • Stash 2.12 does not support Git 1.8.4.3
  • Stash does not support the Apache HTTP Server mod_auth_basic module. 

See Supported platforms.

Known issues

Stash 2.11 update notes

Please also see:

Note that Stash does not support Git 1.8.4.3, nor does Stash support Java 8 yet. See Supported platforms.

Known issues

Stash 2.10 update notes

Please also see:

Note that Stash does not support Git 1.8.4.3. See Supported platforms.

Known issues

Stash 2.9 update notes

Please also see:

Note that Stash does not support Git 1.8.4.3. See Supported platforms.

Pull Request Ref Optimization

When you first start Stash after upgrading to Stash 2.9 a repository update task runs that optimizes the pull request refs for all repositories managed by Stash. It's important that you do not interrupt this update process. You can track the progress of this in the Stash logs. See  BSERV-3469 - Pull request references in the Git repository are never removed after merge or decline Closed .

Backup Client Update Required

Version 1.0.3 of the Stash Backup Client is required to back up Stash 2.9.

Known issues

Stash 2.8 update notes

Please also see:

Known issues

Stash 2.7 update notes

Please also see:

Repository System Information Plugin is now deprecated

The functionality of the repository system information plugin has now been moved into core Stash. The plugin will still work for Stash 2.x versions but is redundant as of Stash 2.7.

MySQL default isolation level

Stash 2.7.x uses READ_COMMITTED instead of the MySQL default isolation level (REPEATABLE_READ). This can result in exceptions when installing or upgrading to 2.7.x, if binary logging is enabled in your MySQL server. More details and a fix can be found in this KB article.

Known issues

Stash 2.6 update notes

Please also see:

Known issues

Loading
P Key Summary Status

Stash 2.5 update notes

Please also see:

Known issues

Limited support for JIRA 4.4.x and earlier

JIRA 4.3+ allows for showing commits associated with issues in JIRA. However, viewing issues within Stash is not supported for JIRA 4.4.x and earlier.

Stash 2.4 update notes

Please also see:

Known issues

Loading
P Key Summary Status

Stash 2.3 update notes

Please also see the update steps section above.

When upgrading to Stash 2.3 you also need to update the SCM Cache plugin, due to recent Stash API changes.

Known issues

Loading
P Key Summary Status

Stash 2.2 update notes

Please see the update steps section above.

Known issues

Loading
P Key Summary Status

Stash 2.1 update notes

Please also see the update steps section above.

Known issues

Install location for third-party libraries

As of Stash 2.1 you can install third-party libraries and jar files, such as the MySQL JDBC driver, into <Stash home directory>/lib. This has the advantage that files in this location are not overwritten, and lost, when you update Stash.

Microsoft SQL Server JDBC driver

Stash 2.1 now uses the Microsoft SQL Server JDBC driver to access Microsoft SQL Server, instead of using the jTDS driver. In most cases, Stash will automatically swap to using the Microsoft driver on update and no configuration is required.

If Stash was configured to use Microsoft SQL Server by manually entering a JDBC URL, please refer to this guide.

Stash 2.0 update notes

This section provides specific notes for upgrading to Stash 2.0. See also the update steps section above.

Tomcat

For Stash 2.0, Tomcat has been updated from version 6 to 7. As part of that update, the server.xml file has changed. If you have customized server.xml (for example, for port, path or hostname), you can not simply copy your own version across to the updated Stash; you must reapply your customizations to the server.xml file for the new version of Stash.

If you were running Stash as a Windows service and are upgrading from 1.x to 2.x you will need to reinstall the Stash service to make it use Tomcat 7.

To uninstall the Stash service you need to execute following commands from <STASH DISTRIBUTION DIR>\bin:

> net stop <service name>
> service.bat uninstall <service name>

You can call this command without the service name if you installed the Stash service with a default name.

After the service is uninstalled you can proceed with the update steps and Running Bitbucket Server as a Windows service instructions to configure Stash 2.x running as a service.

Perl

Stash 2.0 requires Perl for its branch permission functionality. If Perl is unavailable, Stash 2.0 will not start.

On Windows machines, Perl will only have been installed by the Git installer if the correct install option was chosen. See Installing and upgrading Git.

Existing Git hooks

In order to support Branch Permissions, Stash 2.0 moves existing hooks in the pre-receive and post-receive folders under  <Stash home directory>/data/repositories/NNNN/hooks (where NNN is the internal repository id)  to .../hooks/pre-receive.d/10_custom or .../hooks/post-receive.d/10_custom. Consequently, custom hooks that use relative path names (e.g. "./foo.sh" or "../dir/foo.sh") will be broken by the update to Stash 2.0.

Deprecation of Internet Explorer 8

Support for Internet Explorer 8 is deprecated from the release of Stash 2.0. The official end-of-support date is yet to be determined. See Supported platforms for details.

Known issues

Checking for known issues and troubleshooting

If something is not working correctly after you have completed the steps above to update your Stash installation, please check for known Stash issues and try troubleshooting your update as described below:

  • Check for known issues. Known issues can be seen in the STASH project on our issue tracker.
  • Stash Knowledge Base. Sometimes we find out about a problem with the latest version of Stash after we have released the software. In such cases we publish information in the Stash Knowledge Base.
  • If you encounter a problem during the update and cannot solve it, please create a support ticket and one of our support engineers will help you.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport