0ct0pu5/Pico
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Remove contents of _plugin-dev/basics.md regarding Picos core

Browse source 
This happens in favour of a separate CONTRIBUTING.md on GitHub, see d29e2c1. The website should stick to plugin and theme development.
This commit is contained in:
Daniel Rudolf 2015-10-29 17:03:31 +01:00
parent 512ded9c6e
commit fed2a66d90
1 changed files with 3 additions and 65 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

68
_plugin-dev/basics.md
View file

@ -1,74 +1,12 @@
---
toc:
basics:
_title: Basics
versioning: Versioning
branches: Branches
build--release: Build & Release
basics: Basics
nav: 1
---
# Basics
Creating your own content for Pico is *easy*.
Inside the root Pico folder, all *themes* reside in the `themes` directory, and all *plugins* in the `plugins` directory. (As a developer, you may have changed these paths and/or directory names when you initialized Pico.)
Inside the root Pico folder, all *themes* reside in the `themes` directory, and all *plugins* in the `plugins` directory.
Note that if you are submitting pull requests they should be small (i.e. one feature per request), stick to existing coding conventions and documentation should be updated if required.
# Versioning
Pico uses Semantic Versioning. Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
For more information see the [http://semver.org](http://semver.org) website.
# Branches
The `master` branch contains the current development version of Pico,
*it is likely unstable and __not ready__ for production use*.
When creating a new development branch, please follow this prefixing convention:
- `feature/` for bigger features,
- `enhancement/` for smaller improvements, and
- `bugfix/` for bug fixes.
As soon as development reaches a point where feedback is appreciated, a PR is opened. After some time (very soon for bug fixes, and other improvements should have a reasonable feedback phase) the PR is merged into `master` and the development branch can be deleted.
# Build & Release
Defined below is a specification to which the Build and Release process of Pico should follow. We use `travis-ci` to automate the process, and each commit to `master` should be releasable.
### Commit phase
- Commit changes
- Create & Push Git tag
- Trigger automatic build process...
Example commit message:
Pico 1.0.1
* [New] ...
* [Changed] ...
*Please submit pull-requests with a properly
formatted commit message/SemVer increase to avoid the need for manual amendments.*
### Analysis phase
- Run through `scrutinizer-ci`?
### Packaging phase
- Run composer locally
- Create a ZIP archive (so vendor/ is included)
- Build documentation, output goes to a new folder in the `gh-pages` branch
### Release phase
- Create new Git release at tag
- Upload ZIP archive
- Upload documentation to the `gh-pages` branch
- Set Symlink for latest documentation (http://picocms.org/docs/latest)
- Update release information on GitHub with:
- Release title (taken from changelog)
- Changelog
### Announcements
- Where to announce new Pico release?
If you want to contribute to Picos core please refer to our [CONTRIBUTING.md](https://github.com/picocms/Pico/blob/master/CONTRIBUTING.md) on GitHub.