## Existing docs

### Configuration

tibet config '~' just prints the single value of /usr/local/src/TPI/TIBET
should this maybe be `tibet config path` instead?

Make a note that `TP.sys.cfg` is the same as `TP.sys.getcfg` - otherwise it's
too confusing (or change `TP.sys.cfg` to `TP.sys.getcfg` in all places so that
it's symmetrical with `TP.sys.setcfg` - that would be symmetrical with the `TDS`
version too).


### Deployment

#### Releasing

TIBET projects also support releasing (project version stamping and git branch
tagging) out of the box using two commands: `tibet version` and `tibet release`.

These two commands support a standard pattern for managing project versioning
and releases. The `tibet version` command updates internal project files
(`package.json` and others) with the latest versioning information using the
[semver versioning standard](https://semver.org). The `tibet release` command
manages git branches to perform a release.

Let's see how this works in practice by trying with a new project.

##### Versioning

When you clone a TIBET project, it automatically sets the project version at
`0.1.0`.

```
tibet clone testproject
cd testproject
tibet init
````

The package.json file now has a version of `0.1.0`. Before we bump the version,
we need to make sure our project has been initialized with `git` and that at
least one commit has been done. This is because the `tibet version` command uses
`git` metadata.

```
git init
git add .
git commit -m "Initial commit"
```

Now that we have an initial commit, we can use the `tibet version` command.

```
tibet version --patch --suffix final
Set version 0.1.1 (+g2ad61f88d4.1618882437935) ? Type 'yes' to continue:
```

This command will bump the `semver` 'patch' level and will append no suffix to
the version ('final'). The command can also bump the 'major' and 'minor levels
via the `--major` and `--minor` flags and can append different suffixes like
'beta' and 'rc' by using different values for the `--suffix` flag. See the man
page for `tibet version` for more information on all of the flags and values.

If you type 'yes' to the above, TIBET stamps the new version number in 4
different files in the system. These are used by various parts of the TIBET
machinery to keep your app up-to-date. It is a good idea to commit these as
well:

```
git add package.json public/TIBET-INF/cfg/testproject.xml public/TIBET-INF/cfg/main.xml public/src/templates/version.js
git commit -m "Bumped patch version for release"
```

##### Building a package for release

TIBET supports minification, gzipping and brotliing your application using the
`tibet build` command. While you can specify individual flags `--minify`,
`--gzip` and `--brotli`, `tibet build` also supports a `--release` convenience
flag:

```
tibet build --release
```

##### Release branch management

TIBET's authors have found that developing on one branch and releasing on
another is a great way to keep things organized. The `tibet release` command
codifies this into a convenient command.

```
tibet release
```

While specifics about how this command works can be found in its man page,
here's a quick summary:

1. Verifies that the current branch is the 'source' branch. The source branch
defaults to `develop` - override by setting the `cli.release.source` config
property in your project. See [TIBET Configuration](configuration.html).

2. Verifies that the source branch is not dirty (can override with the `--dirty` flag).

3. Verifies that the source branch is up-to-date with its remote (can override with the `--local` flag). The remote defaults to `origin` - override by setting the `cli.release.remote` config property in your project.

4. Runs `tibet lint --clean` to lint the codebase. This uses tools such as `eslint` and `stylelint` to lint your application's codebase.

5. Tags the source branch using {tag}-{branchname}. Pushes this to the {remote}/{branchname}

6. Checks out the 'target' branch. The target branch defaults to `master` - override by setting the `cli.release.target` config property in your project.

7. Verifies that the target branch is up-to-date with its remote.

8. Merges the source branch into the target branch.

9. Commits the changes to the target branch.

10. Tags the commit with the release tag (the value TIBET computed using the
`tibet version` command above).

11. Pushes the commit and related tag to the remote.

12. Checks out the source branch.

## New docs


