chore: release 3.0.0 (#2216)
This commit is contained in:
Jonas L
GitHub
parent
d03fe5bf7d
commit
96ded62c32
124 changed files with 105 additions and 16 deletions
|
|
@ -0,0 +1 @@
|
|||
label: Development
|
||||
|
|
@ -0,0 +1,149 @@
|
|||
---
|
||||
title: Development environment
|
||||
---
|
||||
|
||||
## Docker-compose
|
||||
|
||||
To setup a docker-compose development environment, run the following commands:
|
||||
|
||||
```bash
|
||||
# Clean and build
|
||||
make clean
|
||||
cp .env.dev .env
|
||||
docker-compose build
|
||||
|
||||
# Setup
|
||||
docker-compose run --rm legacy make build
|
||||
docker-compose run --rm api libretime-api migrate
|
||||
|
||||
# Run
|
||||
docker-compose up -d
|
||||
docker-compose logs -f
|
||||
```
|
||||
|
||||
## Vagrant
|
||||
|
||||
To use Vagrant, you need to install a virtualization engine: [VirtualBox](https://www.virtualbox.org) or Libvirt. The [vagrant-vbguest] package on Github can help maintain guest extensions on host systems using VirtualBox.
|
||||
|
||||
:::tip
|
||||
|
||||
If you try run a libvirt provided box after using a VirtualBox one, you will receive an
|
||||
error:
|
||||
|
||||
```
|
||||
Error while activating network:
|
||||
Call to virNetworkCreate failed: internal error: Network is already in use by interface vboxnet0.
|
||||
```
|
||||
|
||||
This is fixed by stopping virtualbox and re-creating the vagrant box:
|
||||
|
||||
```bash
|
||||
sudo systemctl stop virtualbox
|
||||
vagrant destroy bionic
|
||||
vagrant up bionic --provider=libvirt
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### Installing Libvirt
|
||||
|
||||
On Debian and Ubuntu:
|
||||
|
||||
1. Install Vagrant
|
||||
|
||||
```bash
|
||||
sudo apt install vagrant vagrant-libvirt libvirt-daemon-system vagrant-mutate libvirt-dev
|
||||
sudo usermod -aG libvirt $USER
|
||||
```
|
||||
|
||||
2. Reboot your computer, and then run
|
||||
|
||||
```bash
|
||||
vagrant box add bento/ubuntu-18.04 --provider=virtualbox
|
||||
vagrant mutate bento/ubuntu-18.04 libvirt
|
||||
vagrant up bionic --provider=libvirt
|
||||
```
|
||||
|
||||
On other distributions, you will need to install [libvirt](https://libvirt.org/) and `vagrant-mutate` and then run
|
||||
|
||||
```bash
|
||||
vagrant plugin install vagrant-libvirt
|
||||
sudo usermod -a -G libvirt $USER
|
||||
|
||||
# Reboot
|
||||
|
||||
vagrant plugin install vagrant-mutate
|
||||
vagrant box fetch bento/ubuntu-18.04
|
||||
vagrant mutate bento/ubuntu-18.04 libvirt
|
||||
vagrant up bionic --provider=libvirt
|
||||
```
|
||||
|
||||
### Starting LibreTime Vagrant
|
||||
|
||||
To get started you clone the repo and run `vagrant up`. The command accepts a parameter to
|
||||
change the default provider if you have multiple installed. This can be done by appending
|
||||
`--provider=virtualbox` or `--provider=libvirt` as applicable.
|
||||
|
||||
```bash
|
||||
git clone https://github.com/libretime/libretime
|
||||
cd libretime
|
||||
vagrant up bionic
|
||||
```
|
||||
|
||||
If everything works out, you will find LibreTime on [port 8080](http://localhost:8080)
|
||||
and Icecast on [port 8000](http://localhost:8000).
|
||||
|
||||
Once you reach the web setup GUI you can click through it using the default values. To
|
||||
connect to the vagrant machine you can run `vagrant ssh bionic` in the libretime
|
||||
directory.
|
||||
|
||||
### Alternative OS installations
|
||||
|
||||
With the above instructions LibreTime is installed on Ubuntu Bionic. The Vagrant setup
|
||||
offers the option to choose a different operation system according to you needs.
|
||||
|
||||
| OS | Command | Comment |
|
||||
| ------------ | --------------------- | -------------------------------- |
|
||||
| Debian 10 | `vagrant up buster` | Install on Debian Buster. |
|
||||
| Debian 11 | `vagrant up bullseye` | Install on Debian Bullseye. |
|
||||
| Ubuntu 18.04 | `vagrant up bionic` | Install on Ubuntu Bionic Beaver. |
|
||||
| Ubuntu 20.04 | `vagrant up focal` | Install on Ubuntu Focal Fossa. |
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
If anything fails during the initial provisioning step you can try running `vagrant provision`
|
||||
to re-run the installer.
|
||||
|
||||
If you only want to re-run parts of the installer, use `--provision-with $step`. The
|
||||
supported steps are `prepare` and `install`.
|
||||
|
||||
## Multipass
|
||||
|
||||
[Multipass](https://multipass.run) is a tool for easily setting up Ubuntu VMs on Windows, Mac, and Linux.
|
||||
Similar to Docker, Multipass works through a CLI. To use, clone this repo and then create a new Multipass VM.
|
||||
|
||||
```
|
||||
git clone https://github.com/libretime/libretime
|
||||
cd libretime
|
||||
multipass launch bionic -n ltTEST --cloud-init cloud-init.yaml
|
||||
multipass shell ltTEST
|
||||
```
|
||||
|
||||
Multipass isn't currently able to do an automated install from the cloud-init script.
|
||||
After you enter the shell for the first time, you will still need to [run the LibreTime installer](../../admin-manual/setup/install.md).
|
||||
|
||||
The IP address of your new VM can be found by running `multipass list`. Copy and paste it into your web browser to access the LibreTime interface and complete the setup wizard.
|
||||
|
||||
You can stop the VM with `multipass stop ltTEST` and restart with `multipass start ltTEST`.
|
||||
If you want to delete the image and start again, run `multipass delete ltTEST && multipass purge`.
|
||||
|
||||
### Cloud-init options in cloud-init.yaml
|
||||
|
||||
You may wish to change the below fields as per your location.
|
||||
|
||||
```yaml
|
||||
timezone: America/New York # change as needed
|
||||
ntp:
|
||||
pools: ["north-america.pool.ntp.org"]
|
||||
servers: ["0.north-america.pool.ntp.org", "0.pool.ntp.org"]
|
||||
```
|
||||
|
|
@ -0,0 +1,168 @@
|
|||
---
|
||||
title: Releases
|
||||
---
|
||||
|
||||
## Distributions releases support
|
||||
|
||||
New releases target the current stable distributions release, and development should prepare for future stable distributions releases.
|
||||
|
||||
- We recommend installing LibreTime on the current stable distributions.
|
||||
- Maintenance only releases will provide bug and security fixes for stable and old stable distributions.
|
||||
|
||||
| | Ubuntu 18.04 | Debian 10 | Ubuntu 20.04 | Debian 11 |
|
||||
| ------------ | :----------: | :---------: | :----------: | :---------: |
|
||||
| Release date | 2018-04-26 | 2019-07-06 | 2020-04-23 | 2021-08-14 |
|
||||
| End of life | 2023-04 | 2024-06 | 2025-04 | 2026-06 |
|
||||
| Versions | | | | |
|
||||
| 3.0.x | maintenance | maintenance | recommended | recommended |
|
||||
|
||||
## Versioning schema
|
||||
|
||||
We follow the [Semantic Versioning](https://semver.org/spec/v2.0.0.html) standards.
|
||||
|
||||
In a nutshell, given a version number `MAJOR.MINOR.PATCH` we increment the:
|
||||
|
||||
1. `MAJOR` version when we make incompatible API changes,
|
||||
2. `MINOR` version when we add functionality in a backwards-compatible manner, and
|
||||
3. `PATCH` version when we make backwards-compatible bug fixes.
|
||||
|
||||
## Releasing a new version
|
||||
|
||||
This guide walks you through the steps required to release a new version of LibreTime.
|
||||
|
||||
:::caution
|
||||
|
||||
This guide is still a work in progress, and doesn't cover every use cases. Depending on
|
||||
the version bump, some steps might be wrong. For example, in case of a patch release,
|
||||
the documentation requires different changes.
|
||||
|
||||
:::
|
||||
|
||||
Before releasing a new version, make sure linter don't fail and tests are passing.
|
||||
|
||||
Start by cleaning the repository and make sure you don't have uncommitted changes:
|
||||
|
||||
```
|
||||
git checkout main
|
||||
make clean
|
||||
git status
|
||||
```
|
||||
|
||||
Choose the next version based the our [versioning schema](#versioning-schema):
|
||||
|
||||
```bash
|
||||
export VERSION=3.0.0-beta.0
|
||||
```
|
||||
|
||||
Create a new `release-$VERSION` branch and release commit to prepare a release pull request:
|
||||
|
||||
```bash
|
||||
git checkout -b "release-$VERSION"
|
||||
export COMMIT_MESSAGE="chore: release $VERSION"
|
||||
git commit --allow-empty --message="$COMMIT_MESSAGE"
|
||||
```
|
||||
|
||||
### 1. Version bump
|
||||
|
||||
Write the new `$VERSION` to the VERSION file, and bump the python packages version:
|
||||
|
||||
```bash
|
||||
bash tools/bump-python-version.sh "$VERSION"
|
||||
|
||||
git add .
|
||||
git commit --fixup ":/$COMMIT_MESSAGE"
|
||||
```
|
||||
|
||||
### 2. Release note
|
||||
|
||||
Prepare a new release note based on the `docs/releases/unreleased.md` file. Be sure that
|
||||
the filename match the releases notes naming conventions:
|
||||
|
||||
```bash
|
||||
ls -l docs/releases/
|
||||
cp docs/releases/unreleased.md docs/releases/$VERSION.md
|
||||
```
|
||||
|
||||
The release note file must be updated with:
|
||||
|
||||
- the version and date of this release,
|
||||
- an auto generated features and bug fixes changelog,
|
||||
- instructions for upgrading,
|
||||
- deprecation notices,
|
||||
- remove empty sections.
|
||||
|
||||
Reset and clean the `docs/releases/unreleased.md` file for a future version.
|
||||
|
||||
Update the Github release creation job to use the new release note file in `.github/workflows/release.yml`.
|
||||
|
||||
Commit the release note changes:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit --fixup ":/$COMMIT_MESSAGE"
|
||||
```
|
||||
|
||||
### 3. Website and docs
|
||||
|
||||
Update the version in the website files, the files that need changing are:
|
||||
|
||||
- `website/vars.js`
|
||||
- `website/versions.json`
|
||||
|
||||
Replace the old versioned docs with the current docs:
|
||||
|
||||
```bash
|
||||
mv website/versioned_sidebars/version-*-sidebars.json website/versioned_sidebars/version-$VERSION-sidebars.json
|
||||
|
||||
rm -R website/versioned_docs/version-*
|
||||
cp -R docs website/versioned_docs/version-$VERSION
|
||||
```
|
||||
|
||||
Commit the website and docs changes:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit --fixup ":/$COMMIT_MESSAGE"
|
||||
```
|
||||
|
||||
### 4. Create a new pull request
|
||||
|
||||
Squash the changes and open a pull request for others to review:
|
||||
|
||||
```bash
|
||||
git rebase --autosquash --interactive main
|
||||
```
|
||||
|
||||
Merge the pull request when it's reviewed and ready.
|
||||
|
||||
### 5. Create and push a tag
|
||||
|
||||
Pull the merged release commit:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull upstream main
|
||||
```
|
||||
|
||||
Make sure `HEAD` is the previously merged release commit and tag it with the new version:
|
||||
|
||||
```bash
|
||||
git show --quiet
|
||||
|
||||
git tag -a -m "$VERSION" "$VERSION"
|
||||
```
|
||||
|
||||
Generate the changelog for the newly tagged version:
|
||||
|
||||
```bash
|
||||
make changelog
|
||||
|
||||
git add .
|
||||
git commit -m "chore: generate changelog for $VERSION"
|
||||
```
|
||||
|
||||
Push the tag upstream to finalize the release process:
|
||||
|
||||
```bash
|
||||
git push upstream main --follow-tags
|
||||
```
|
||||
Loading…
Add table
Add a link
Reference in a new issue