# 1.0.0 (2023-08-03)

### Bug Fixes

* allow major version 3 or 4 of `semantic-release/error` ([f0faec8b](f0faec8b))
* fine-tune logging output ([9563f013](9563f013))
* **package:** add `./` prefix to exports ([4249398f](4249398f))

### Features

* allow `tag` in plugin config for default tag replacement ([6f0b6e2c](6f0b6e2c))
* plugin at `@semantic-release/dockerode-tag` ([53744514](53744514))

Moves everything into `.gitlab-ci.yml`

Requires bumping the plugins as they depend on the breaking change to
ECMAscript modules:

- `@semantic-release/commit-analyzer@^10`
- `@semantic-release/gitlab@^12`
- `@semantic-release/release-notes-generator@^11`

We already import it as a ECMAscript module so the breaking
change does not affect us.

It is available in NodeJS 15 which is below our lowest
version of NodeJS 18.

We do not have a package registry enabled on our GitLab at this time.

Prevent an attempt to publish the package.

`semantic-release` 20 will be ESM first and only work on
NodeJS 18+. Prepare for that now by dropping old versions
in the CI.

We do not use anything from the breaking API change.

Makes it much easier to track major changes

We have a circular dependency on between this project and
the release of `ci/templates`. To open source this project
we need to make sure that we can continuously deploy it
without the need for `ci/templates`.

Once we open source `ci/templates` we can revert the changes.

We have a circular dependencies on this project and the
`semantic-release` projects that this project uses for
releasing itself.

Moving them temporarily inside the project.

We use the `ci/templates` one

We previous defaulted the `tag` of an image to be `${nextRelease.version}`.
However, we may want to overide this default when doing tag replacement.

A common use case for this if the incoming tag has parts to it:

```json
tag: "${tag.split('-').slice(0,-1).join('-')}-${nextRelease.version}"
images:
  "${CI_REGISTRY_IMAGE}/node:16-${CI_COMMIT_SHA}"
  "${CI_REGISTRY_IMAGE}/node:18-${CI_COMMIT_SHA}"
```

Otherwise `require` cannot load it from NodeJS

Make use of `logger.success` to give helpful guidance to the
user.

Move some of the logging to `debug` because it is noisy.