Strip master of all optional macros

[TheoPannetier]

Updating branches to match the conventional naming structure:

• master becomes the default branch, which will mirror the public version. Contains the stable version of the code, available to users. Does not contain any of the optional macros (such as RS_CONTAIN, BUTTERFLYDISP, GOBYMODEL etc).
• develop is the working branch all devs interact with, and from which new changes are poured into master. Feature branches are created from develop, and eventually merge back into it.

develop does not contain macros either to make our (devs) life easier. Instead, I have created a dedicated branch macro which lives in parallel with master, although it is not necessarily mirrored on the public repo. New changes made in RangeShifter are added to macros as well upon release, at the same time as master, by pulling changes from either develop or from master (by definition they should be equivalent upon release). I have re-added all optional macros as new changes on macro, so that git considers the corresponding code lines as new and doesn't decide to remove them when we pull changes from develop/master into macros.

Eventually, we coudl also split macro into multiple branches, one for each alternative version of RangeShifter (e.g. contain, butterfly_disp. goby_model).

[JetteReeg]

Hi Theo, I already commented on the other merge (regarding git subtree; all changes on files in the RScore directory need to be also pushed to the RScore repository (by using git subtrees)). So here I am only commenting on your suggestions regarding the branches:

• having the master branch as the mirror to the public version, without the optional macros would be fine for me. However, within the RScore repository, we would need to have a master branch for each frontend (so far batch and Rpackage) as they rely on different macros. The R package need to the the RCPP macro.
• With feature branches you mean branches that are only created to add a new feature (which was implemented on one of the develop branches) to the master branch, correct? If so, I would be fine with having a development branch without macros. But again, you would need development branches in RScore for each frontend.

Best, Jette

[TheoPannetier]

having the master branch as the mirror to the public version, without the optional macros would be fine for me. However, within the RScore repository, we would need to have a master branch for each frontend (so far batch and Rpackage) as they rely on different macros. The R package need to the the RCPP macro.

To clarify: by optional macro, I meant the ones that change the way the simulation runs, but are not necessary to compile the standard version of the software or any of the frontend: RS_CONTAIN, BUTTERFLYDISP, GOBYMODEL, etc. I would keep macros like RS_BATCH, RS_GUI, LINUX_CLUSTER or RS_RCPP indeed on the main branch. Would that make sense? Then we would only need a single master (and develop) branch for the core code, shared by all frontends through the RScore folder + subtree.

With feature branches you mean branches that are only created to add a new feature (which was implemented on one of the develop branches) to the master branch, correct? If so, I would be fine with having a development branch without macros. But again, you would need development branches in RScore for each frontend.

By feature branch, I meant branches on which we work on implementing some new feature for the software, e.g. "new_genetics" or "competition". Once a satisfying, stable state has been reached, the feature branch is merged into develop (which is eventually merged into master). Just like master and develop, we keep all the macros necessary to compile/run the frontends on such feature branches, so no need to keep one branch per frontend.

[TheoPannetier]

Just realised the PR title was misleading, sorry!

[TheoPannetier]

Following the discussion on #1 I'm just going to redo these changes within RScore. Closing this PR, but we can keep discussing the changes here!

[JetteReeg]

I would keep macros like RS_BATCH, RS_GUI, LINUX_CLUSTER or RS_RCPP indeed on the main branch. Would that make sense? Then we would only need a single master (and develop) branch for the core code, shared by all frontends through the RScore folder + subtree.

Yes, that would be fine for me. However, the question remains, whether we would have 2 different release branches then for R and batch to get rid of all macros in a release version. I guess that would be fine?

By feature branch, I meant branches on which we work on implementing some new feature for the software, e.g. "new_genetics" or "competition".

I think so far all of the optional macros included somehow 'new features' and at some point we would discuss, which features should be finally integrated into the official version. E.g. if I remember correctly, we already discussed that some functions of CONTAIN and SEASONAL e.g. should be integrated. So your idea would be, to keep all the older versions on the one hand inside an overall 'macros' branch as well as in specific development branches, e.g. RS_CONTAIN. Just so we have them centrally stored in the same repository. But whenever we would now stark working on new features or would like to modify the official version, we would create a new branch from the developement? Is that correct?

[TheoPannetier]

Just continuing this conversation in https://github.com/JetteReeg/RScore/pull/2 - it seems we're discussing the same points there, and the discussion is more about the core code than the batch version / GUI :)