Pre-Modularization Issues

[kinggoesgaming]

These first few issues till the first horizontal rule need to be discussed separately.

• [x] Separation of "configuration settings" and "player data" into different files. Currently the config file for EssentialCmds holds both of these information. Other than making things crowded, this approach makes things hard for the user of the plugin to customize the plugin since they have to first figure what is a setting and what is a stored player data, and overall makes one huge file, which also affects io.
• [ ] Permissions need to be organised. currently the permissions are set randomly. however if we are to split the plugin up, we need to organise the permissions in the format of essentialcmds.<module>.someperm.someperm or essence.<module>.someperm.someperm

---

• [x] Comments in configs. Currently there are no comments in the configs. As the config options are pretty simple right now there is no need. However in the future there might be time when an open makes sense to us but not to the user. This is where comments provide help as they provide a little understanding.
• [ ] Two main branches:
  • master: The branch from which the github releases are built from.
  • dev: This branch is what is what our current branch looks like... just push into this and stuff "might" be broken but whatever lets fix it. This is where stability and stuff is checked before it is merged with master.

• [ ] Project version format change: Currently the version format is not suitable for multi-layer module structure. currently the format used is x.x(buildId) and the that format is not healthy in terms build systems as well. The new format that i suggest is as follows: |- X.Y.Z

  |- X: is the compatibility check number. Whenever there is changes that break compatibility , This version has to be bumped and other version numbers reset. |- Y: the major version number. Only bumped if big feature is added or a major bug is fixed. |- Z: the bug fix version number. Only used for bug fixes and completing a feature that was previously started.

---

At this point I would also say that you keep continuing work on adding features as modules are likely gonna take time as the above issues need to be solved before they are done.

---

[kinggoesgaming]

Blocks #13

[kinggoesgaming]

closing as it is decided not to be implemented here, but instead in nucleus