Release Notes



Mar 21 2018

The Bamboo plugin can now update Jira status based on the build & merge progress. The Jira task directly related to the branch being tested will be updated to reflect the actual status.

Example: when a build starts, the Jira 'status' workflow attribute can be set to 'Testing', then updated to 'Reopened', 'Closed' or even 'Merged' depending on the final result.

For further info about DevOps, trunk based development and task-per-branch check:

* A DevOps Primer

* DevOps with Bamboo and Plastic

To configure this new feature, enable Monitor Jira to filter branches configuration field in Bamboo's Repository configuration. New textbox fields will appear to set the status of the Jira issue with a desired value when Bamboo triggers the following events:

* A plan branch starts its build plan

* A plan branch build fails

* A plan branch build succeeds

* A plan branch is automatically merged (only if gatekeeper automatic merge feature is enabled).

The allowed values for these fields are <issue_status>



REMARK: remember the <issue_status> has to be previously created in Jira Workflow!


Windows GUI: Several fixes have been done in the 2D version tree:

* Set correct initial date in the branch explorer calculated taking into account the history revisions date.

* Fix view options: version tree vs complete Branch Explorer. They were not doing anything at all. By default, the version tree is set. So, only relevant changesets are displayed.


Windows GUI: Fixed an error deleting repositories using the "Del" key when the selection was empty.

Internal and public releases

The Plastic SCM development team works in short iterations delivering frequent releases.Our goal is to have at least one new release every week, with new functionalities, bug fixes and performance tweaks.

Every 'weekly' release is not published to our customers, but we like to detail each of them in the release notes so users can easily follow what we achieved on every short iteration.

The releases marked with the word "public" are the ones we do publish on the website. The ones marked as "internal" are the releases we create in-house to keep the project moving week after week.

Version numbering

Starting in Plastic SCM 4.0 the version numbering schema has been modified:

  • major.minor.compatibility.buildnumber

  • Sample: means:
    • 8 -> major release number
    • 0 -> minor release number
    • 16 -> compatibility -> all clients and servers with "16" in the compat number are compatible, even if the build number changes
    • 3333 -> internal build number