Now that the first release candidate for the 1.1.0 release has been
tagged, the stable branch for the 1.1 series has been created and we
can start developing the 1.1.0 release on main. This commit bumps all
the version strings from 1.1.0 to 1.2.0 (and the backport branch for
mergify to stable/1.1) accordingly to differentiate the main branch
from 1.1.*.
Now that the first release candidate for the 1.0.0 release has been
tagged, the stable branch for the 1.0 series has been created and we
can start developing the 1.1.0 release on main. This commit bumps all
the version strings from 1.0.0 to 1.1.0 (and the backport branch for
mergify to 1.0) accordingly to differentiate the main branch from
1.0.*.
* Bump main branch version post 0.45.0rc1 tag
Now that the first release candidate for the 0.45.0 release has been
tagged, the stable branch for the 0.45 series has been created and we
can start developing the 1.0.0 release on main. This commit bumps all
the version strings from 0.45.0 to 1.0.0 (and the backport branch for
mergify to 0.45) accordingly to differentiate the main branch from
0.45.*.
* Handle 1.0 in docs build
This opens development on `main` for the next minor version of *Qiskit*
(no longer to be called Terra). The version number is jumping to 0.45
to bring the version of `qiskit-terra` in line with `qiskit` (currently
the metapackge); starting from "Qiskit 0.45", this repository will be
called `qiskit` only, and the packages `qiskit` and `qiskit-terra` will
be unified, at least as far as Python packaging allows us to do.
Now that the first release candidate for the 0.24.0 release has been
tagged, the stable branch for the 0.24 series has been created and we
can start developing the 0.25.0 release on main. This commit bumps all
the version strings from 0.24.0 to 0.25.0 (and the backport branch for
mergify to 0.24) accordingly to differentiate the main branch from
0.24.*.
Due to recent changes in the mergify configuration/service the merge
queue feature of mergify is no longer working as expected. It's not
clear if this just a temporary bug in mergify, a longer term change in
behavior (which requires all PR authors to be registered on mergify), or
some incompatibility between the github api and mergify. However,
because we're no longer able to rely on it we've moved to using github's
native merge queue feature [1][2] instead. Since this new merge queue
would conflict with mergify's this commit removes the merge queue
configuration from the mergify configuration. The configuration for
stable backporting is left in place because github doesn't natively
offer that feature and it appears to still work fine.
[1] https://github.blog/changelog/2023-02-08-pull-request-merge-queue-public-beta/
[2] https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue
* Bump main branch version post 0.23.0rc1 tag
Now that the first release candidate for the 0.23.0 release has been
tagged, the stable branch for the 0.23 series has been created and we
can start developing the 0.24.0 release on main. This commit bumps all
the version strings from 0.23.0 to 0.24.0 (and the backport branch for
mergify to 0.23) accordingly to differentiate the main branch from
0.23.*.
* Bump version number in cargo lock file too
Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
* Bump main branch version post rc tag
Now that the first release candidate for the 0.22.0 release has been
tagged, the stable branch for the 0.22 series has been created and we
can start developing the 0.23.0 release on main. This commit bumps all
the version strings from 0.22.0 to 0.23.0 (and the backport branch for
mergify to 0.22) accordingly to differentiate the main branch from
0.22.*.
* Move release notes to dedicated directory too
* Update Cargo too
Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
* Bump version strings post pre-release
Now that qiskit-terra 0.21.0rc0 is out the door we should bump the version
string on main to show the source version we're installing is newer
than what's been pre-released.
* Move 0.21 release notes into a separate directory
* Update cargo.toml too
Now that qiskit-terra 0.20.0 is out the door we should bump the version
string on main to show the source version we're installing is newer
than what's been released.
Now that qiskit-terra 0.19.0 is out the door we should bump the version
string on master to show the source version we're installing is newer
than what's been released.
Now that qiskit-terra 0.18.0 is out the door we should bump the version
string on master to show the source version we're installing is newer
than what's been released.
In #6188 and #6117 we changed the mergify configuration to use the smart
strict mode which silently maintains a merge queue for us. This option
has recently been superseded by building explict merge queues that
enable more rich control over how PRs to merge get queue together. [1]
This commit switches the mergify config to use an explicit queue for
merging to give us more explicit control over how mergify is going to
merge PRs for us. This also opens up new options if we were to have a
mergify subscription at a future date, primarily speculative testing on
the merge queue [2] which will enable better throughput because it
validates the potential future state all at once and lets us run testing
in parallel.
[1] https://docs.mergify.io/actions/queue/
[2] https://docs.mergify.io/actions/queue/#speculative-checks
* Bump version strings post release
Now that qiskit-terra 0.17.0 is out the door we should bump the version
string on master to show the source version we're installing is newer
than what's been released.
* Bump mergify config
@mtreinish noticed that strict: smart+fasttrack would be better than strict: smart,
in that it will move PRs already based on master to the head of the merge queue.
Now that qiskit-terra 0.15.0 is out the door we should bump the version
string on master to show the source version we're installing is newer
than what's been released.
Now that qiskit-terra 0.14.0 is out the door we should bump the version
string on master to show the source version we're installing is newer
than what's been released.
Now that qiskit-terra 0.13.0 is out the door we should bump the version
string on master to show the source version we're installing is newer
than what's been released.
This commit adds a rule to the mergify configuration to automatically
attempt to backport a PR with the stable backport potential label on it.
If there is a merge conflict we'll still have to manually backport, but
for cleanly applying backports this saves us the manual step of having
to backport commits. The one caveat here is that we will have to
remember to bump the stable branch number post release to the new
branch, which means there are now 3 locations to update after a release
instead of 2.
* Add explicit PR trigger to azure pipelines
According to the trigger docs for azure [1] not specifying a pr field in
the config should have an implicit pr trigger on all branches.
However, this default PR trigger has stopped working. This commit adds a
manual pr trigger field in an attempt to workaround this issue. It has
been reported that manually adding the PR trigger will resolve the
issue. [2]
[1] https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#pr-triggers
[2] https://developercommunity.visualstudio.com/comments/949243/view.html
* Revert "Update mergify config to require travis not azure (#3975)"
This reverts commit f534d904b0. This is no
longer needed because azure-pipelines is working again.
* Revert "Add back full travis config during azure pipelines outage (#3973)"
This reverts commit b50f30c03e.
Since we're in the middle of an azure pipelines outage we've temporarily
switched to using travis as our sole ci provider (see #3973) until the
situation is resolve. However, the mergify config is hard coded to check
for azure pipelines to report success before continuing. This commit
updates the mergify config so that the automerge tag will continue to
work while we're relying on travis for all of our ci.
This commit adds a basic configuration for using mergify.io. It simply
will just squash merge the PR if it's been approved and passes ci. The
configuration documentation for the service can be found here:
https://doc.mergify.io/configuration.html
Elena Peña Tapia