[FEATURE] Support diffent types of file hashing

[jirafeau.git] / CONTRIBUTING.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index f7f21ed79399c5b92d03ca563031c924057059dc..dfa5d5520edf5e175e8bb9df4fa25cd64e7cd83f 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -24,6 +24,7 @@ view only to show the most importants files and their role.
 ```
 .
 ├── admin.php : administration interface to manage links and files
+├── docker : folder containing some configuration files to run Jirafeau in docker
 ├── f.php : permits to download files or show the download page
 ├── index.php : provides a web interface to interact with API
 ├── script.php : API interface (all file actions happen here - upload, deletion, etc)
@@ -45,10 +46,10 @@ view only to show the most importants files and their role.
 └── var-xxxxxxx : the users folder containing all data (auto generated, not versionized)
     ├── async : chunks of uploaded files (not succressfull yet) 
     ├── files : all files that have been uploaded successfully
-        ├── [hashed file name] : the original file
-        ├── [hashed file name]_count : count many links to this file exist
+    │   ├── [hashed file name] : the original file
+    │   └── [hashed file name]_count : count many links to this file exist
     └── links : all links, including meta-informations, pointing to files
-        â\94\9c── [link] : the link file, includes which original file should be used and some meta data like creation date, expiration time
+        â\94\94── [link] : the link file, includes which original file should be used and some meta data like creation date, expiration time
 ```
 
 ## Translations
@@ -84,3 +85,17 @@ Quick walktrough:
 * Feature is reviewed
   * MR accepted: Reviewer checks out »next-release« branch and cherry-picks the commit ```git checkout next-release; git cherry-pick be4369641; git push```
   * MR declined: Reviewer add some notes, Developer rebases his branch, adds neccessary changes, force pushes the branch, ask a reviewer to review the changes in the merge request ticket (as Gitlab recognizes them automatically) ```git checkout some-feature; git rebase upstream/next-release``` …[add changes]… ```git add -A, git commit --amend; git push -f```
+
+## New Releases
+
+* If the release is not done for security purposes, freeze next-branch for at least week.
+* Compare the [»next-release« branch to »master«](https://gitlab.com/mojo42/Jirafeau/compare/master...next-release)
+* Add a list of noteworthy features and bugfixes to the README
+* Fill upgrade procedure in README
+* Change the version, using [semantic versioning](http://semver.org/), in ```settings.php```
+* Merge »next-release« branch to »master«
+* Update the demo page
+* Tag the »master« with the new version
+* Push branch and tag
+* Build & push new docker image
+* Dance a little