Contributing

From Lasers-Enigma Documentation
Jump to: navigation, search

How to contribute

Contact us on discord.

You will need a gitlab account to be able to commit your push branches on our repository: gitlab.com/lasersenigma/lasersenigma.

Developers guidelines

We are a team. Let's dev together !

If you are not motivated to start working it is usually for 2 reasons:

  • You have no task that motivates you => Contact us in order to find a new task that you would like and be motivated by.
  • You don't know what to do next. The task is complicated and you need help to define how to continue. => Contact us in order to think together of the next steps.

If you are blocked on a problem during more than an hour, please inform us. A fresh look can sometimes be problem solving. We WILL help you. Don't fear to annoy us: if we are not available we will just tell you so.

Use the prebuilt environment

The virtual machine already contains:

  • NetBeans
    • the main project plugged on our gitlab repositories (build.xml configured to deploy the plugin's jar on each server each time you build).
    • the api project plugged on our gitlab repositories (build.xml configured to deploy the plugin's jar on each server each time you build).
  • IntelliJ (the main project + the api project both plugged on our gitlab repositories)
    • the main project plugged on our gitlab repositories (build.xml configured to deploy the plugin's jar on each server each time you build).
    • the api project plugged on our gitlab repositories (build.xml configured to deploy the plugin's jar on each server each time you build).
  • MariaDB (3 MySQL databases, one per server).
  • 4 spigot servers (on each supported version) configured to use the MySQL backend. Ready to be used with the debugger.
  • DBeaver with its connection configured to see the databases.
  • Some useful bookmarks in the browser
  • Virtualbox guest addons to be able to drag and drop from/to the vm.
  • Open ports to be able to connect to the servers from your computer's minecraft game
  • Links configured in the Xfce panel to start each servers quickly

Login: lasersenigma

Password: admin

Use alt + maj to switch from the french to the english keyboard.

Setup your own environment

  • Use IntelliJ or NetBeans or VisualStudioCode. Eclipse is not recommended.
  git config --unset user.name
  git config --unset user.email
  git config --global --unset user.name
  git config --global --unset user.email
  git config –-global user.name "Mon Nom"
  git config --global user.email "Mon Nom <monemail@email.com>"
  git config --global remote.origin.prune true
  • Import the 2 maven projects from gitlab (The "Clone with ssh" url).
  • Build each projet (maven clean install). If it does not build contact us.
  • Start your server.
  • Inside the configuration deactivate notifications for new beta version (and don't forget to modify your language).
  • Restart your server.
  • In both project, create a copy of build-example.xml named build.xml.
  • Modify this file in order to copy the built jar to each servers /plugins/ folder.
  • Build both project again.
  • Start you server and check that it works ingame.
  • Configure you debugger (You can find tutorials about how to do this on NetBeans or on IntelliJ)
  • Follow the first puzzle tutorial to create yourself a testing chamber in order to be able to quickly test the new features you will code.

Start a new task

  • Take a look at the issues that are affected to you on both project's boards (and think about priorities) before selecting a new task to do.
  • Assign yourself to the task if it is not already done.
  • Inside the project's issue board, drag and drop the file to the "Doing section".
  • if you are not specifically told to do otherwise, you must ALWAYS start from master. so checkout and pull master first.
  • Create a new branch using the following name guideline:
  <domain>_<3/5 letters from your nickname>_<fix|evol|refacto>_<issue number>_<task name>
  Exemple: worldedit_bzx_fix_29_copy_paste


Commit your code

Commiting regularly is very important for security, planning and reviewing reasons. Don't wait weeks before commiting your code. You do not need your branch to build to commit.

  • If you think your code is ready to be merged, TEST YOUR CODE ! If it contains things that can potentially be broken on some specific minecraft versions please do the effort of testing it on each minecraft versions.
  • Review the differences before commiting.
    • using your IDE or the 'git diff' command if you use git bash.
    • If you use git bash, prefer the usage of 'git add -p' instead of 'git add .'
  • Put a clear commit name. If your commit closes and issue you can write 'Closes #<Issue Number>' in order to automatically close the issue when the merge request will be accepted.
  • Push your branch
  • If the branch is ready to be merged into master, create a merge request and assign it to one of the lead developers. Select delete branch when it will be merged.
  • If the branch is not ready and if you still want your code to be reviewed, send a message in the #developers discord channel.

Versions

  • master => -SNAPSHOT (can be betatested. mainly working but potentially unstable)
  • tag => released versions (like 6.0.1. stable)
  • other branches => not published on artifactory (unfinished work. Very probably unstable. potentially private)
  • tag format: X.Y.Z
    • X = increments when a big refactoring was done (like when multi-version architecture was created)
    • Y = increments when a new feature was added (We forgot to do it for mirror blocks and the update notifier)
    • Z = increments when a fix or any small modification is done (We forgot to do it for the many many fix we did recently)

Never delete '-SNAPSHOT' from the version specified in /pom.xml <properties><revision>X.Y.Z-SNAPSHOT</revision></properties> gitlab will do it automatically when it builds a tag.