[BUGFIX] always prefer using HTML5 features if available

[jirafeau_mojo42.git] / CONTRIBUTING.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index f7f21ed79399c5b92d03ca563031c924057059dc..245a6e7812b43df9c6f57ccc5d0ec5264383fbf6 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
 ```
 .
 ├── 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)
 ├── 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
 └── 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
     └── 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
 ```
 
 ## Translations


@@ -80,7 +81,23 @@ Quick walktrough:
 * Fork the original repository, clone the own repository, add the original repository as upstream
 * Checkout »next-release« branch ```git checkout next-release```
 * Create a new branch on top of that one, e.g. »some-feature« ```git checkout -b some-feature```
 * Fork the original repository, clone the own repository, add the original repository as upstream
 * Checkout »next-release« branch ```git checkout next-release```
 * Create a new branch on top of that one, e.g. »some-feature« ```git checkout -b some-feature```

+* Make your change
+* You may check if the project is still [REUSE Compliant](https://reuse.software/) by running `docker run -v $(pwd):/code --rm fsfe/reuse /bin/sh -c "cd /code && reuse lint"`

 * Commit changes → push → send merge request ```git add -A; git commit; git push``` MR via GitLab (link shown in console)
 * 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```
 * Commit changes → push → send merge request ```git add -A; git commit; git push``` MR via GitLab (link shown in console)
 * 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: create a new issue and freeze next-release 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 `CHANGELOG.md`
+* Add eventual upgrade procedure to `CHANGELOG.md`
+* 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