Towards v1

.gitignore

@@ -93,3 +93,6 @@ trash
 !resources/macOS/MapMap.icns
 
 *.json
+
+# Local development notes
+KNOWN-WARNINGS.txt

CODE_OF_CONDUCT.md

@@ -34,7 +34,7 @@ This Code of Conduct applies both within project spaces and in public spaces whe
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at info@mapmap.info. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at mapmap@artpluscode.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
 
 Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
 

CONTRIBUTING.md

@@ -13,6 +13,14 @@ It really helps us efficiently process your contribution!
 [Report a bug](#bug-reports)   
 [Request a feature](#feature-requests)   
 [Contribute code](#contributing-code)  
+[Coding style](#coding-style)  
+[Building](#building)  
+[Version numbers](#version-numbers)  
+[Files overview](#files-overview)  
+[Code management with Git](#code-management-with-git)  
+[Make a release](#make-a-release)  
+[Project file version number](#project-file-version-number)  
+[Qt resources system](#qt-resources-system)  
 
  ## <a id='bug-reports'></a>Report a bug
 
@@ -44,7 +52,7 @@ We already have a formal [roadmap](https://github.com/mapmapteam/mapmap/wiki/Roa
 Feature requests are therefore mostly a way of us discussing/feeling out together where we'd like the project to go. 
 This can sometimes involve a lot of discussion, as everyone uses MapMap differently. You can join the [MapMap Slack team](https://mapmap.slack.com/) and use the `#feature` channel channel for general questions or discussion about new features
 
-Feature requests are created as Github Issues, just like bugs.t
+Feature requests are created as Github Issues, just like bugs.
 Feature requests are also where code that you or anyone else would like to include in a future pull request is **discussed before being implemented!**
 If you're writing code to add a new feature that you think would be awesome to have in the core, that's great! 
 But please make sure it's been discussed as a feature request _before_ you submit your pull request, as that increases the chances that your pull request will be accepted. 
@@ -63,7 +71,7 @@ As with most open source projects, the fastest way to get a feature made is to m
 We are more likely to accept your code if we feel like it has been discussed already. 
 If you are submitting a new feature, it's best if the feature has been discussed beforehand, either as a [feature request](#feature-requests) or on the [Slack](https://mapmap.slack.com/) or the [mailing list](https://listes.koumbit.net/cgi-bin/mailman/listinfo/mapmap-list-mapmap.info).
 
-- Please read the [code style guidelines](https://github.com/mapmapteam/mapmap/wiki/MapMap-Code-Style) and make sure your code conforms to them.
+- Please read the [coding style](#coding-style) section below and make sure your code conforms to it.
 If in doubt, try and match the style and practices you find in the code you are working with.
 - Please write _descriptive commit messages_ for each of the commits that you make.
 They don't have to be in-depth, just a brief summary of what the commit contains. A page describing how well-written commit messages look like can be found [here](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
@@ -88,5 +96,90 @@ This granularity makes the code easier to deal with in cases where some things h
 - All pull requests that contain changes that need to be in the changelog **must include relevant additions to `NEWS`**. Use previous entries as a guide for style/indentation/etc.
 - In the comments field on your new pull request, enter a description of everything that the code in the pull request does. 
   - This description is the first contact most of the core team will have with your code, so you should use it to explain why your pull request is awesome and we should accept it. 
-  - Reference any issues or bugs in the [MapMap issue tracker](github.com/openframeworks/openFrameworks/issues) that are relevant to your pull request using `#issue number` notation, eg to reference issue __1234__ write `#1234`.
+  - Reference any issues or bugs in the [MapMap issue tracker](https://github.com/mapmapteam/mapmap/issues) that are relevant to your pull request using `#issue number` notation, eg to reference issue __1234__ write `#1234`.
   - Mention if the code has been tested and on what platform.
+
+## <a id='coding-style'></a>Coding style
+
+* Indent with 2 spaces
+* Opening curly braces on a new line
+* Function and method names camelCase, with lowercase first letter
+* Class names CamelCase
+* Private data members with an underscore as a prefix: `_likeThis`
+* File names all lowercase
+* Always add spaces between operators such as `+`, `-`, `/`, `*`, casts, etc. (except pointers and references)
+
+## <a id='building'></a>Building
+
+See INSTALL.
+
+You will need to install markdown to build some of the documentation that comes with the software.
+
+## <a id='version-numbers'></a>Version numbers
+
+We use Semantic Versioning 2.0.0. 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.
+See http://semver.org/
+
+We want the 0 series to be backward-compatible. That means that a project created with MapMap 0.1 should still work with MapMap 0.99, if we ever get to such a version number. When we will break this backward-compatibilty, we will start the 1 series and provide a migration script. This script might be ran from the command-line or on the Web. The other thing we need to be backward-compatible is the OSC interface. The rest of the software can change. This includes the names of the menu items and the appearance of the user interface. We will try to keep these consistent, though.
+
+## <a id='files-overview'></a>Files overview
+
+* CONTRIBUTING.md: What to know to contribute to the project.
+* INSTALL: Instructions to build and install the software.
+* NEWS: Release notes for each tag.
+* README: The short documentation at the root of the project
+* TODO: You can put things to do there, or use https://github.com/mapmapteam/mapmap
+* images/: Images part of the GUI.
+* prototypes/ : Contains prototypes. Please ask the project maintainer before removing some of these.
+* docs/informations/*.md Markdown files to generate the About dialog
+
+## <a id='code-management-with-git'></a>Code management with Git
+
+* We develop in the develop branch. The master branch is only for the latest tag.
+* Create a branch for each new features. Merge it to develop.
+* Create release-x.y.z branch for releases.
+* If possible, avoid merges, and use git rebase instead. (like in the GNOME projects)
+* Create a x.y branch for each x.y major.minor version series.
+* For a new release, merge develop to master (or your branch to the major.minor branch if it's a bugfix release) and then tag it there.
+* In doubt, ask the release manager.
+
+## <a id='make-a-release'></a>Make a release
+
+* If it's a new feature, increment minor. If it's bugfix, increment micro. If it's not backward-compatible, increment major.
+* Create a release-x.y.z branch
+* Verify the version number:
+  * vim -o VERSION.txt DMGVERSION.txt mapmap.pro docs/Doxyfile NEWS src/core/MM.cpp
+  * VERSION.txt
+  * VERSION in MM.cpp
+  * VERSION in mapmap.pro
+  * PROJECT_NUMBER in Doxyfile
+* Edit NEWS - update with the news for the release you are about to make
+* Run ./scripts/update-changelog.sh and commit the changes
+* Maybe update the docs/informations/osc.md file and run scripts/update-osc.sh and commit the changes
+* Maybe update the docs/informations/CONTRIBUTORS.md file and run scripts/update-contributors.sh and commit the changes
+* run make
+* run ./sh_build_doc.sh
+* merge to master, or to the major.minor branch
+* run ./sh_make_tarball.sh
+* then untar it, cd to that dir and build the whole thing to see if it works
+* git tag x.y.z
+* go back to your release branch
+* increment micro (or minor) version number in the files above.
+* merge into develop.
+* keep developing.
+
+## <a id='project-file-version-number'></a>Project file version number
+
+* Update its minor number when you introduce new features.
+* Update its major number when it's not backward-compatible anymore with its previous versions.
+* Generally, we should follow the MapMap version, when new changes are introduced. (no need to increment it otherwise)
+
+## <a id='qt-resources-system'></a>Qt resources system
+
+* The mapmap.pro file is where the packaging is done
+* The mapmap.qrc file is where we specify which resources are packaged with the app.
+* Images are set there. They are then available as a path-like alias such as ":/fullscreen"
+* See https://doc.qt.io/qt-6/resources.html

README.md

@@ -42,9 +42,9 @@ or else the menu will not show.
 
 Authors
 -------
-* Sofian Audry: lead developer, user interface designer, project manager.
+* Alexandre Quessy: lead developer, release manager, technical writer, project manager.
+* Sofian Audry: original lead developer, user interface designer, project manager.
 * Dame Diongue: developer.
-* Alexandre Quessy: release manager, developer, technical writer, project manager.
 * Mike Latona: user interface designer.
 * Vasilis Liaskovitis: developer.
 

docs/informations/CONTRIBUTORS.html

@@ -1,9 +1,9 @@
 <h1>Authors</h1>
 
 <ul>
-<li>Sofian Audry: lead developer, user interface designer, project manager.</li>
+<li>Alexandre Quessy: lead developer, release manager, technical writer, project manager.</li>
+<li>Sofian Audry: original lead developer, user interface designer, project manager.</li>
 <li>Dame Diongue: developer.</li>
-<li>Alexandre Quessy: release manager, developer, technical writer, project manager.</li>
 <li>Mike Latona: user interface designer.</li>
 <li>Vasilis Liaskovitis: developer.</li>
 </ul>

docs/informations/CONTRIBUTORS.md

@@ -1,10 +1,10 @@
 ## Authors
 
-- Sofian Audry: lead developer, user interface designer, project
-    manager.
-- Dame Diongue: developer.
-- Alexandre Quessy: release manager, developer, technical writer,
+- Alexandre Quessy: lead developer, release manager, technical writer,
+    project manager.
+- Sofian Audry: original lead developer, user interface designer,
     project manager.
+- Dame Diongue: developer.
 - Mike Latona: user interface designer.
 - Vasilis Liaskovitis: developer.