91a21c2729
- standardize page names, rework documentation structure, update TOC - use same example paths everywhere - level 1 titles on all pages - fix broken links - .md suffix on all page links (works both from readthedocs and github repository views) **Server:** A full and concise installation guide with examples is a frequent request. The documentation should provide such a guide for basic installation needs, while explaining alternative/advanced configuration at the end. Links to reference guides and documentation should be used more frequently to avoid recommending an outdated or excessively complex configuration. - server: move most server-related info to server-configuration.md, cleanup/shorten - server: update list of php dependencies/libraries, link to composer.json - server: installation: support 3 install methods (from release zip, from sources, using docker) - server: installation: use rsync instead of mv as mv results will change depending of taget directory already existing or not - server: add example/basic usage of certbot - server, upgrade, installation: update file permissions setup, use sudo for upgrade operations in webserver document root - server: apache: add comments to configuration, fix and factorize file permissions setup, set cache-control header, deny access to dotfiles, add missing apache config steps, add http->https redirect example - server: nginx: refactor nginx configuration, add comments, DO log access to denied/protected files - server: add links to MDN for x-forwarded-* http headers explanation, cleanup/clarify robots.txt and crawlers section - server: bump file upload size limit to 100MB we have reports of bookmark exports weighing +40MB - i have a 13MB one here - server: simplify phpinfo documentation - server: move backup and restore information to dedicated page - docker: move all docker docs to Docker.md, simplify/ docker setup, add docker-compose.yml example, replace docker-101 with docker cheatsheet - troubleshooting: move all troubleshooting documentation to troubleshooting.md **Usage:** - index: add getting started section on index page - features/usage: move all usage-related documentation to usage.md, add links from the main feature list to corresponding usage docs, clarify/reword features list - shaarli configuration: add note about configuring from web interface **Removed:** - remove obsolete/orphan images - remove obsolete shaarchiver example - remove outdated "decode datastore content" snippet **Development:** - development: move development-related docs (static analysis, CI, unit tests, 3rd party libs, link structure/directory, guidelines, security....) to dev/ directory - development: Merge several pages to development.md - **Breaking change?:** remove mentions of 'stable' branch, switch to new branch/release model (master=latest commit, release=latest tag) - **Breaking change?:** refer to base sharing unit as "Shaare" everywhere (TODO: reflect changes in the code?) doc: update featues list/link to usage.md for details - development: directory structure: add note about required file permissions - .travis-ci.yml: add comments - .htaccess: add comment
145 lines
4.5 KiB
Markdown
145 lines
4.5 KiB
Markdown
# Release Shaarli
|
|
|
|
## Requirements
|
|
|
|
This guide assumes that you have:
|
|
|
|
- a GPG key matching your GitHub authentication credentials/email (the email address identified by the GPG key is the same as the one in your `~/.gitconfig`)
|
|
- a GitHub fork of Shaarli
|
|
- a local clone of your Shaarli fork, with the following remotes:
|
|
- `origin` pointing to your GitHub fork
|
|
- `upstream` pointing to the main Shaarli repository
|
|
- maintainer permissions on the main Shaarli repository, to:
|
|
- push the signed tag
|
|
- create a new release
|
|
- [Composer](https://getcomposer.org/) needs to be installed
|
|
- The [venv](https://docs.python.org/3/library/venv.html) Python 3 module needs to be installed for HTML documentation generation.
|
|
|
|
## Release notes and `CHANGELOG.md`
|
|
|
|
GitHub allows drafting the release notes for the upcoming release, from the [Releases](https://github.com/shaarli/Shaarli/releases) page. This way, the release note can be drafted while contributions are merged to `master`. See http://keepachangelog.com/en/0.3.0/ for changelog formatting.
|
|
|
|
`CHANGELOG.md` should contain the same information as the release note draft for the upcoming version. Update it to:
|
|
|
|
- add new entries (additions, fixes, etc.)
|
|
- mark the current version as released by setting its date and link
|
|
- add a new section for the future unreleased version
|
|
|
|
```bash
|
|
## [v0.x.y](https://github.com/shaarli/Shaarli/releases/tag/v0.x.y) - UNRELEASES
|
|
|
|
### Added
|
|
|
|
### Changed
|
|
|
|
### Fixed
|
|
|
|
### Removed
|
|
|
|
### Deprecated
|
|
|
|
### Security
|
|
|
|
```
|
|
|
|
|
|
## Update the list of Git contributors
|
|
|
|
```bash
|
|
$ make authors
|
|
$ git commit -s -m "Update AUTHORS"
|
|
```
|
|
|
|
## Create and merge a Pull Request
|
|
|
|
Create a Pull Request to marge changes from your remote, into `master` in the community Shaarli repository, and have it merged.
|
|
|
|
|
|
## Create the release branch and update shaarli_version.php
|
|
|
|
```bash
|
|
# fetch latest changes from master to your local copy
|
|
git checkout master
|
|
git pull upstream master
|
|
|
|
# If releasing a new minor version, create a release branch
|
|
$ git checkout -b v0.x
|
|
|
|
# Bump shaarli_version.php from dev to 0.x.0, **without the v**
|
|
$ vim shaarli_version.php
|
|
$ git add shaarli_version
|
|
$ git commit -s -m "Bump Shaarli version to v0.x.0"
|
|
$ git push upstream v0.x
|
|
```
|
|
|
|
## Create and push a signed tag
|
|
|
|
Git [tags](http://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project#Tagging-Your-Releases) are used to identify specific revisions with a unique version number that follows [semantic versioning](https://semver.org/)
|
|
|
|
```bash
|
|
# update your local copy
|
|
git checkout v0.5
|
|
git pull upstream v0.5
|
|
|
|
# create a signed tag
|
|
git tag -s -m "Release v0.5.0" v0.5.0
|
|
|
|
# push the tag to upstream
|
|
git push --tags upstream
|
|
```
|
|
|
|
Here is how to verify a signed tag. [`v0.5.0`](https://github.com/shaarli/Shaarli/releases/tag/v0.5.0) is the first GPG-signed tag pushed on the Community Shaarli. Let's have a look at its signature!
|
|
|
|
```bash
|
|
# update the list of available tags
|
|
git fetch upstream
|
|
|
|
# get the SHA1 reference of the tag
|
|
git show-ref tags/v0.5.0
|
|
# gives: f7762cf803f03f5caf4b8078359a63783d0090c1 refs/tags/v0.5.0
|
|
|
|
# verify the tag signature information
|
|
git verify-tag f7762cf803f03f5caf4b8078359a63783d0090c1
|
|
# gpg: Signature made Thu 30 Jul 2015 11:46:34 CEST using RSA key ID 4100DF6F
|
|
# gpg: Good signature from "VirtualTam <virtualtam@flibidi.net>" [ultimate]
|
|
```
|
|
|
|
## Publish the GitHub release
|
|
|
|
- In the `master` banch, update version badges in `README.md` to point to the newly released Shaarli version
|
|
- Update the previously drafted [release](https://github.com/shaarli/Shaarli/releases) (notes, tag) and publish it
|
|
- Profit!
|
|
|
|
|
|
## Generate full release zip archives
|
|
|
|
Release archives will contain Shaarli code plus all required third-party libraries. They are useful for users who:
|
|
|
|
- have no SSH access, no possibility to install PHP packages/server extensions, no possibility to run scripts (shared hosting)
|
|
- do not want to install build/dev dependencies on their server
|
|
|
|
`git checkout` the appropriate branch, then:
|
|
|
|
```bash
|
|
# checkout the appropriate branch
|
|
git checkout 0.x.y
|
|
# generate zip archives
|
|
make release_archive
|
|
```
|
|
|
|
This will create `shaarli-v0.x.y-full.tar`, `shaarli-v0.x.y-full.zip`. These archives need to be manually uploaded on the previously created GitHub [release](https://github.com/shaarli/Shaarli/releases).
|
|
|
|
|
|
### Update the `latest` branch
|
|
|
|
```bash
|
|
# checkout the 'latest' branch
|
|
git checkout latest
|
|
# merge changes from your newly published release branch
|
|
git merge v0.x.y
|
|
# fix eventual conflicts with git mergetool...
|
|
# run tests
|
|
make test
|
|
# push the latest branch
|
|
git push upstream latest
|
|
```
|