Installer Generation

[dtg3]

Installer generation needs to be demystified.

The idea behind this issue is to make installer generation more consistent if done by any member of the development team and to reduce the risk of having to re-learn how to do this when the person/people who "always generated the installer" are not available or working on the project.

Options are:

1. Add all the necessary supplemental projects to the eclipse repository so it can be generated by anyone with a simple button press, export, menu option, etc.
2. Have highly detailed instructions with images (think explaining it to someone like they are four years old) on a wiki page.

My personal preference is both to be honest.

[clptrsn]

How do we want the directory structure of this in the repo. Do we want three top levels with iTrace-Eclipse, iTrace_Eclipse_Plugin, and iTrace_Site or do we want to maintain the project being the top level and having the iTrace installer directories inside of the iTrace project directory.

[shbonita]

@dtg3 this question is for you!

[dtg3]

I don’t work with Eclipse at all regularly so my knowledge of its project organization standards is limited.

Ideally opening the Eclipse plugin project should also open the supporting projects (like VS does for solutions). If that feature relies on directory structure, then use whichever supports that.

If directory organization is only for our purposes I would say the root of the repo has three folders each containing resources for their respective part of the overall project. The readme, license, and any Git files would also stay in the root where they are now.

[dtg3]

Now that development has been merged into master, a new branch based on master should be made to perform the project modifications to simplify installer generation. Those will be the ONLY changes that will get merged into master once it is complete and tested. Afterwards we will make a new tag to indicate the same base code and features, but modified for the installer. That will become the base for new development. If bugs and issues start pouring in and fixes are required before this can be completed, the plan may need to change.

[dtg3]

Per meeting discussion hotfix releases will be:
[Current release number].[short sha]
e.g: 0.1.0.9df1ee1

This will be better than using a date/timestamp as we will know exactly what changes are in the release build.

When testing is complete, the new release will feature the next version number:
hotfix: 0.1.1
full release: 0.2.0