Version 2.2.6 (Dec 13, 2017)

Version 2.2.5 (Nov 3, 2017)

Add a utility API to allow implementation plugins to use a standard mechanism for normalizing SCM URIs in order to assist comparisons (no user visible changes)

Version 2.2.4 (Nov 2, 2017)

Clarify the help text for the built in filters. The built in filters treat the SCMHead name as a name, no special processing. A lot of people were wondering why when they set a filter like master feature/* why none of the PRs were building... the reason being that PR-123 does not match the filter. When using the filters built in to SCM-API you probably want something like master feature/* PR-* to get PRs to build. An alternative filter implementation that probably does what you actually want is SCM Filter Branch PR Plugin as that will filter non-change requests like the built in filters but has a special case for PRs where instead it filters those based on the PR target head rather than the name of the PR (which will always be PR-... unless the SCMSource uses a different prefix for its change request concept )

Version 2.0.1 (Jan 16, 2016)

(I will be updating the rest of the changes and removing this line after the chain of releases is done - SC)

Version 2.0.1-beta-1 (Dec 16, 2016)

Released to experimental update center to allow testing the downstream changes in github-branch-source and bitbucket-branch-source (both of which need upgrading to at least 2.0.0-beta-1 if you have them installed on your master)

Version 2.0 (Dec 7, 2016)

JENKINS-38987 Added pronouns to assist consuming plugins to name concepts like: SCMHead; SCMSource; and SCMNavigator with SCM specific idiomatic names, e.g. GitHub can respectively provide pronouns "Branch"/"Tag"/"Pull request"; "Repository"; "Server", whereas something like Accurev could provide pronouns "Stream"/"Snapshot"; "Depot"; "Repository". The pronouns are more relevant for SCMHead as typically each SCM implementation is likely to have more than one type of head: mainlines, branches, tags, change requests, etc

JENKINS-39355 Various API improvements that make it easier to implement/consume SCM API including the addition of an event system to allow SCM implementations to consolidate push event handling from their backing SCM server.

JENKINS-40138 SCMHead.getActions() should never have been introduced into the SCM API. JENKINS-33309 was a mistake. The API is now marked as DoNotUse and is non-functional. Replacement API for the correct way to access the corresponding information have been documented.

Added a mock SCM implementation in the tests-jar so that consumers can write unit tests of their implementation without needing to create SCM servers and manipulate SCM repositories to generate events or test conditions.