From 55397d6736f4cdd240b22b7e0a4bb169a5fafcd4 Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Mon, 7 Oct 2019 18:40:16 +0200 Subject: [PATCH 01/16] Live app link to the website gallery (#143). --- README.md | 2 +- inst/application/report.Rmd | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 78245a8..e2fc063 100644 --- a/README.md +++ b/README.md @@ -29,7 +29,7 @@ Unlike other pension calculators, this makes results transparent, comparable, an The **SmaRP** Shiny app is deployed to Google Cloud Platform (using [docker containers](https://www.docker.com/resources/what-container)) and can be -accessed at https://mirai-solutions.ch/apps/smarp/. +accessed at https://mirai-solutions.ch/gallery/smarp. The (development version of) **SmaRP** can also be served locally by installing the package from GitHub diff --git a/inst/application/report.Rmd b/inst/application/report.Rmd index fb62132..4025e5f 100644 --- a/inst/application/report.Rmd +++ b/inst/application/report.Rmd @@ -105,7 +105,7 @@ Kinder <- format(round(params$Kinder, 2), nsmall = 0) Smart Retirement Planning (**SmaRP**) is a [Mirai Solutions](https://mirai-solutions.ch/) initiative designed to guide people working in Switzerland towards a strategic decision-making process for their retirement. -It is implemented as an [R Shiny](https://shiny.rstudio.com/) pension calculator web app, in the form of an R package. The source code is available on [GitHub](https://github.com/miraisolutions/SmaRP.git) and the app itself online at http://mirai-solutions.ch/apps/smarp/. +It is implemented as an [R Shiny](https://shiny.rstudio.com/) pension calculator web app, in the form of an R package. The source code is available on [GitHub](https://github.com/miraisolutions/SmaRP.git) and the app itself online at https://mirai-solutions.ch/gallery/smarp. **SmaRP** is based on the [three pillars pension system](https://en.wikipedia.org/wiki/Pension_system_in_Switzerland) and reflects the complexity of its legal framework. The bulk of the retirement income are the second and third pillar, which employees can actively manage and make decisions impacting their total pension fund at retirement. The first pillar is not considered as it is a pay-as-you-go universal system whose benefits depend on the income earned during the working life and the number of years contributed. In addition, since non-mandatory contributions are tax favored, SmaRP incorporates an additional fund -the Tax benefits- to outline the effects of those tax reliefs on the long run. From 70af4c8d1e5a19f24d0cf98fecd8ddce7c652826 Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Tue, 8 Oct 2019 09:45:45 +0000 Subject: [PATCH 02/16] Link to GKE deployment instructions README (#143). * TODO added for possibly allowing to run the GCR image. --- README.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index e2fc063..315fec5 100644 --- a/README.md +++ b/README.md @@ -27,9 +27,16 @@ Unlike other pension calculators, this makes results transparent, comparable, an ## Using SmaRP -The **SmaRP** Shiny app is deployed to Google Cloud Platform (using [docker -containers](https://www.docker.com/resources/what-container)) and can be -accessed at https://mirai-solutions.ch/gallery/smarp. +The **SmaRP** Shiny app is [deployed](gke#readme) to Google Cloud Platform +(using [Docker containers](https://www.docker.com/resources/what-container)) and +can be accessed at https://mirai-solutions.ch/gallery/smarp. + The (development version of) **SmaRP** can also be served locally by installing the package from GitHub From a0c1c0565ecc462b7178def7688f3fd442a5d075 Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Tue, 8 Oct 2019 09:55:30 +0000 Subject: [PATCH 03/16] Include GitFlow and release considerations (#143). * Point to a new dedicated README for details. --- .Rbuildignore | 3 +- README.md | 7 +++-- git-flow/README.md | 73 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 80 insertions(+), 3 deletions(-) create mode 100644 git-flow/README.md diff --git a/.Rbuildignore b/.Rbuildignore index 7e89be4..328518f 100644 --- a/.Rbuildignore +++ b/.Rbuildignore @@ -2,11 +2,12 @@ ^doc$ ^man-roxygen$ ^Meta$ +^\.Rproj\.user$ ^.*\.Rproj$ -^\.Rproj\.user$ ^Dockerfile$ ^docker$ ^cloudbuild\.yaml$ ^gke$ +^git-flow$ ^inst/application/data/taxdata$ diff --git a/README.md b/README.md index 315fec5..e8670a2 100644 --- a/README.md +++ b/README.md @@ -38,15 +38,18 @@ docker run --rm eu.gcr.io/mirai-sbb/smarp ``` --> -The (development version of) **SmaRP** can also be served locally by installing the package from GitHub +The R package **SmaRP** can be installed from GitHub with ``` r devtools::install_github("miraisolutions/SmaRP", build_opts = "") ``` -and running +and used to serve the app locally from R via ``` r SmaRP::launch_application() ``` +Since **SmaRP** is developed using a [GitFlow](git-flow#readme) approach, the `master` branch always reflects the _latest_ [release](https://github.com/miraisolutions/SmaRP/releases) of the live app, whereas branch `develop` collects the latest delivered developments for the _next_ releases, which can be installed locally via +``` r +devtools::install_github("miraisolutions/SmaRP", "develop", build_opts = "") ## Details and key features diff --git a/git-flow/README.md b/git-flow/README.md new file mode 100644 index 0000000..d553a2a --- /dev/null +++ b/git-flow/README.md @@ -0,0 +1,73 @@ +# GitFlow and Release Model for SmaRP + + +## Branching System + +We use a [**GitFlow**](https://nvie.com/posts/a-successful-git-branching-model/) branching model, where the repository holds two main **branches** with an infinite lifetime: + +- [**`master`**](https://github.com/miraisolutions/SmaRP/tree/master): reflects the [**latest release**](https://github.com/miraisolutions/SmaRP/releases/latest) to production, i.e. the current version of the [live app](https://mirai-solutions.ch/gallery/smarp). +- [**`develop`**](https://github.com/miraisolutions/SmaRP/tree/develop): collects all completed developments for the [**next release**](#release). + +The overall GitFlow branching system is described as follows + +- No work is committed and pushed directly to `master`, which is updated only as part of a [**release**](#release). +- Small (maintenance) work can be done directly in `develop`, however meaningful pieces should be developed in a dedicated **_feature_ branch** created from `develop` and associated to a GitHub issue. By convention, the branch name is of the form `feature/-short-title`. + - Once completed, the feature branch is merged back into `develop` via a pull request. + - Each significant development must be mentioned as a bullet point in the top-section of [**`NEWS.md`**](../NEWS.md) before being pushed to or merged into `develop`, to serve as a change log for the next release. +- **Hot-fixes** that need to be brought in asap, independently of any other pending development, are carried out in a dedicated branch (of the form `hotfix/-short-title`) created from `master`. The branch is merged directly back to `master` as a new **patch release**, and must be also merged into `develop` (or possibly an open _release_ branch). + + +## Versioning and Releases {#release} + +**SmaRP** uses a [**semantic versioning**](https://semver.org/) scheme bound to the version of the underlying R package. The basic versioning scheme `major.minor.patch` (e.g. `1.1.2`) is reserved for release tagging and the `master` branch (which reflects the most recent release). On the other hand, a fourth _development_ component `-9000` is added for the not-yet-released development happening in the `develop` and _feature_ branches. The package version is updated for the next release (see below) just before the merge into `master` (from `develop` or a _release_ branch). Afterwards, `-9000` is added again to the new version for the future development. + +Here we assume that the most recent release is `1.0.0`, hence the version on `develop` is `1.0.0-9000`. +Releases should only happen from a **stable `develop`**, possibly creating a **_release_ branch** for the release preparation, with a name of the form `release/v`, e.g. `release/v1.1.0` for a new _minor_ release. + +1. **Release preparation** + - Consolidate and re-organize the changes in `NEWS.md` (see e.g. Hadley's [recommendations](http://r-pkgs.had.co.nz/release.html#important-files) and [style guide](https://style.tidyverse.org/news.html#news-release)), using the level-3 header `###` for sections if any (nicer rendering in GitHub) + - Changes should have been collected in `NEWS.md` already during development + - Decide on the **next version** based on whether it is a _patch_, _minor_, _major_ release + - For _patch_ changes: `1.0.0-9000` -> `1.0.1` (mainly for hot-fixes) + - For _minor_ changes: `1.0.0-9000` -> `1.1.0` (e.g. any change that affects calculations and numbers in the output, minor app refinements or additions, general maintenance) + - For _major_ changes: `1.0.0-9000` -> `2.0.0` + - Change version number in `NEWS.md` and `DESCRIPTION` files. + +(Note: for the remaining steps, a minor release with `1.1.0` will be used as an example) + +2. **Commit and push** all changes with the comment: `1.1.0 release preps` and `closes` lines for all issues mentioned in the `NEWS.md`, e.g. + + ``` + 1.1.0 release preps + * closes #26 + * closes #38 + ``` +3. Go on GitHub and create a new **pull request** from `develop` (or the _release_ branch) to `master` + - Write title in the form "1.1.0 release" + - Paste as comment the list of changes in `NEWS.md` + - Assign reviewer(s) and set project to SmaRP +4. As part of the review process, make sure the app can be built and run via Docker locally + - Build image with test tag: `docker build -f Dockerfile -t mirai/smarp:test-1.1.0 .` + - Run the app: `docker run --rm -p 80:80 mirai/smarp:test-1.1.0` + - Visit `http://127.0.0.1:80` and test the app + - Type `Ctrl+C` to stop the container, which is automatically removed (`--rm`) + - Cleanup the image: `docker image rm mirai/smarp:test-1.1.0` +5. Once the pull request is merged into `master`, create a **new release on GitHub** ([Code > releases > Draft new release](https://github.com/miraisolutions/SmaRP/releases/new)) + - Tag version: v1.1.0 + - Title: SmaRP 1.1.0 + - Body: Paste as comment the list of changes in `NEWS.md` + - Click on "Publish release" +6. If the release was done from a _release_ branch, a pull request should be created to merge it back into `develop` +7. Prepare for **next version** on `develop` + - Change the `Version` field in `DESCRIPTION` to the development version `1.1.0-9000` + - Create a new heading in `NEWS.md` for `SmaRP 1.1.0-9000` + - Commit and push + + +## References + +* [GitFlow for GitHub](https://datasift.github.io/gitflow) by DataSift. +* [Git and GitHub](http://r-pkgs.had.co.nz/git.html) from Hadley Wickham's [R packages](http://r-pkgs.had.co.nz/). +* [Package versioning](http://r-pkgs.had.co.nz/description.html#version) from Hadley Wickham's [R packages](http://r-pkgs.had.co.nz/). +* [Releasing a package](http://r-pkgs.had.co.nz/release.html) from Hadley Wickham's [R packages](http://r-pkgs.had.co.nz/). + From 049ee3314eed45123a7e138b9e74efa38eade111 Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Tue, 8 Oct 2019 09:58:11 +0000 Subject: [PATCH 04/16] Mention version-stable deployment / development (#143). --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index e8670a2..e5a242a 100644 --- a/README.md +++ b/README.md @@ -50,6 +50,9 @@ SmaRP::launch_application() Since **SmaRP** is developed using a [GitFlow](git-flow#readme) approach, the `master` branch always reflects the _latest_ [release](https://github.com/miraisolutions/SmaRP/releases) of the live app, whereas branch `develop` collects the latest delivered developments for the _next_ releases, which can be installed locally via ``` r devtools::install_github("miraisolutions/SmaRP", "develop", build_opts = "") +``` + +Note that **SmaRP** is deployed using [version-stable](https://github.com/rocker-org/rocker-versioned#readme) images from the [Rocker project](https://www.rocker-project.org/). The target environment of live app is currently bound to R 3.5.3. Therefore, the app is developed and tested with the corresponding version of R and packages, as opposed to the latest available versions. ## Details and key features From 37d579edadb0bbb8c7fe9098df762656a9a2d627 Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Tue, 8 Oct 2019 10:07:54 +0000 Subject: [PATCH 05/16] General README maintenance (#143) --- README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index e5a242a..047513a 100644 --- a/README.md +++ b/README.md @@ -59,11 +59,11 @@ Note that **SmaRP** is deployed using [version-stable](https://github.com/rocker The evolution of the total retirement fund over time is computed by projecting the value of the occupational fund (2nd Pillar), the private fund (3rd Pillar) and the tax relief, thus deriving their contributions at the desired retirement age. -*Contributions to the second Pillar* are calculated from the salary and any additional voluntary purchases. +- _Contributions to the second Pillar_ are calculated from the salary and any additional voluntary purchases. -*Contributions to the third Pillar* are fully voluntary and repeated every year until retirement. +- _Contributions to the third Pillar_ are fully voluntary and repeated every year until retirement. -*Tax savings* are built as an additional fund where tax relieves from a certain year are used as contributions for the next. Tax relieves are calculated using an approximation of the given gross salary and other factors including: residence, civil status, number on kids, etc. +- _Tax savings_ are built as an additional fund where tax relieves from a certain year are used as contributions for the next. Tax relieves are calculated using an approximation of the given gross salary and other factors including: residence, civil status, number on kids, etc. **Results** of the calculation are available in **SmaRP** in 3 different ways: @@ -85,16 +85,16 @@ The evolution of the total retirement fund over time is computed by projecting t ### Source code -Core calculations behind this Shiny app have been implemented via several functions, collected in the main source files [SmaRP/R/core.R](https://github.com/miraisolutions/SmaRP/blob/master/R/core.R) and [SmaRP/R/TaxBenefits.R](https://github.com/miraisolutions/SmaRP/blob/master/R/TaxBenefit.R). +Core calculations behind this Shiny app have been implemented via several functions, collected in the main source files [SmaRP/R/core.R](R/core.R) and [SmaRP/R/TaxBenefits.R](R/TaxBenefit.R). Documentation for the relevant exported functions used in the app is also provided and can be browsed via ``` r help(package = "SmaRP") ``` -On a functional level, the code is covered by extensive [unit tests](https://github.com/miraisolutions/SmaRP/tree/master/tests/testthat). +On a functional level, the code is covered by extensive [unit tests](tests/testthat). -The source code for the app itself is available under [SmaRP/inst/application](https://github.com/miraisolutions/SmaRP/blob/master/inst/application). +The source code for the app itself is available under [SmaRP/inst/application](inst/application). ### Data sources and references @@ -104,7 +104,7 @@ An overview of these components can be found at e.g. https://en.wikipedia.org/wi A more detailed explanation is available on the Swiss [Federal Social Insurance Office](https://www.bsv.admin.ch/bsv/de/home/sozialversicherungen/ueberblick.html) website (in German). -Legal parameters in **SmaRP** are defined in [SmaRP/inst/application/global.R](https://github.com/miraisolutions/SmaRP/blob/master/inst/application/global.R), whereas data is stored under [SmaRP/inst/application/data](https://github.com/miraisolutions/SmaRP/blob/master/inst/application/data). +Legal parameters in **SmaRP** are defined in [SmaRP/inst/application/global.R](inst/application/global.R), whereas data is stored under [SmaRP/inst/application/data](inst/application/data). ### Accuracy From 6552ff89b1cb6ed29e2161a4927ec697773e2e73 Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Tue, 8 Oct 2019 14:05:35 +0000 Subject: [PATCH 06/16] Cleanup legacy commented text. --- README.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/README.md b/README.md index 047513a..e6dc37d 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,3 @@ - From c1f57f962cf33448ee752a3bde00db534c44fe35 Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Tue, 8 Oct 2019 14:24:22 +0000 Subject: [PATCH 07/16] NEWS updated for #143. --- NEWS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/NEWS.md b/NEWS.md index 88fdb41..4d0bb76 100644 --- a/NEWS.md +++ b/NEWS.md @@ -3,6 +3,7 @@ * Add directory with GKE instructions and manifests. * Upgrade deployed app to R 3.5.3 (from R 3.5.1), improve Docker image with refactored Dockerfile (#91). * Removed heavy shinydashboardPlus dependency by using custom collapsible panels (#113). +* Updated links to the live app and README based on website integration, including GitFlow and release details (#143). # SmaRP 1.2.0 From e1c8c9f2cc3dd08d858a0e406868ca6ec8529dac Mon Sep 17 00:00:00 2001 From: Riccardo Porreca Date: Wed, 9 Oct 2019 19:34:34 +0200 Subject: [PATCH 08/16] Apply suggestions from code review Co-Authored-By: nfarabullini <41536517+nfarabullini@users.noreply.github.com> --- README.md | 2 +- git-flow/README.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index e6dc37d..cc71ac2 100644 --- a/README.md +++ b/README.md @@ -37,7 +37,7 @@ and used to serve the app locally from R via ``` r SmaRP::launch_application() ``` -Since **SmaRP** is developed using a [GitFlow](git-flow#readme) approach, the `master` branch always reflects the _latest_ [release](https://github.com/miraisolutions/SmaRP/releases) of the live app, whereas branch `develop` collects the latest delivered developments for the _next_ releases, which can be installed locally via +**SmaRP** is developed using a [GitFlow](git-flow#readme) approach, hence the `master` branch always reflects the _latest_ [release](https://github.com/miraisolutions/SmaRP/releases) of the live app, whereas branch `develop` collects the latest delivered developments for the _next_ releases, which can be installed locally via ``` r devtools::install_github("miraisolutions/SmaRP", "develop", build_opts = "") ``` diff --git a/git-flow/README.md b/git-flow/README.md index d553a2a..d1538fd 100644 --- a/git-flow/README.md +++ b/git-flow/README.md @@ -5,14 +5,14 @@ We use a [**GitFlow**](https://nvie.com/posts/a-successful-git-branching-model/) branching model, where the repository holds two main **branches** with an infinite lifetime: -- [**`master`**](https://github.com/miraisolutions/SmaRP/tree/master): reflects the [**latest release**](https://github.com/miraisolutions/SmaRP/releases/latest) to production, i.e. the current version of the [live app](https://mirai-solutions.ch/gallery/smarp). -- [**`develop`**](https://github.com/miraisolutions/SmaRP/tree/develop): collects all completed developments for the [**next release**](#release). +- [**`master`**](https://github.com/miraisolutions/SmaRP/tree/master) reflects the [**latest release**](https://github.com/miraisolutions/SmaRP/releases/latest) to production, i.e. the current version of the [live app](https://mirai-solutions.ch/gallery/smarp). +- [**`develop`**](https://github.com/miraisolutions/SmaRP/tree/develop) collects all completed developments for the [**next release**](#release). The overall GitFlow branching system is described as follows - No work is committed and pushed directly to `master`, which is updated only as part of a [**release**](#release). - Small (maintenance) work can be done directly in `develop`, however meaningful pieces should be developed in a dedicated **_feature_ branch** created from `develop` and associated to a GitHub issue. By convention, the branch name is of the form `feature/-short-title`. - - Once completed, the feature branch is merged back into `develop` via a pull request. + - Once completed, the branch is merged back into `develop` via a pull request. - Each significant development must be mentioned as a bullet point in the top-section of [**`NEWS.md`**](../NEWS.md) before being pushed to or merged into `develop`, to serve as a change log for the next release. - **Hot-fixes** that need to be brought in asap, independently of any other pending development, are carried out in a dedicated branch (of the form `hotfix/-short-title`) created from `master`. The branch is merged directly back to `master` as a new **patch release**, and must be also merged into `develop` (or possibly an open _release_ branch). From 1f9eb2187281925827289330542431aa0344693c Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Fri, 11 Oct 2019 09:57:19 +0000 Subject: [PATCH 09/16] Mention avoiding specific bugfix branches (#143). * Also aligned italic text for semantic versioning components. --- git-flow/README.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/git-flow/README.md b/git-flow/README.md index d1538fd..b867756 100644 --- a/git-flow/README.md +++ b/git-flow/README.md @@ -11,15 +11,16 @@ We use a [**GitFlow**](https://nvie.com/posts/a-successful-git-branching-model/) The overall GitFlow branching system is described as follows - No work is committed and pushed directly to `master`, which is updated only as part of a [**release**](#release). -- Small (maintenance) work can be done directly in `develop`, however meaningful pieces should be developed in a dedicated **_feature_ branch** created from `develop` and associated to a GitHub issue. By convention, the branch name is of the form `feature/-short-title`. +- Small (maintenance) work can be done directly in `develop`, however meaningful pieces should be developed in a dedicated **_feature_ branch** created from `develop` and associated to a GitHub issue. + - By convention, the branch name is of the form `feature/-short-lowercase-title`. This also applies to bug-fixes (see however below for hot-fixes), where a separate naming like `fix/-xyz` should be avoided (see [nvie/gitflow#24](https://github.com/nvie/gitflow/issues/24)), possibly using something like `feature/-fix-xyz` instead, e.g. `feature/142-fix-p2-interest-rate-step` for [#142](https://github.com/miraisolutions/SmaRP/issues/142). - Once completed, the branch is merged back into `develop` via a pull request. - Each significant development must be mentioned as a bullet point in the top-section of [**`NEWS.md`**](../NEWS.md) before being pushed to or merged into `develop`, to serve as a change log for the next release. -- **Hot-fixes** that need to be brought in asap, independently of any other pending development, are carried out in a dedicated branch (of the form `hotfix/-short-title`) created from `master`. The branch is merged directly back to `master` as a new **patch release**, and must be also merged into `develop` (or possibly an open _release_ branch). +- **Hot-fixes** that need to be brought in asap, independently of any other pending development, are carried out in a dedicated branch (of the form `hotfix/-short-lowercase-title`) created from `master`. The branch is merged directly back to `master` as a new **_patch_ release**, and must be also merged into `develop` (or possibly an open _release_ branch). ## Versioning and Releases {#release} -**SmaRP** uses a [**semantic versioning**](https://semver.org/) scheme bound to the version of the underlying R package. The basic versioning scheme `major.minor.patch` (e.g. `1.1.2`) is reserved for release tagging and the `master` branch (which reflects the most recent release). On the other hand, a fourth _development_ component `-9000` is added for the not-yet-released development happening in the `develop` and _feature_ branches. The package version is updated for the next release (see below) just before the merge into `master` (from `develop` or a _release_ branch). Afterwards, `-9000` is added again to the new version for the future development. +**SmaRP** uses a [**semantic versioning**](https://semver.org/) scheme bound to the version of the underlying R package. The basic versioning scheme _`major.minor.patch`_ (e.g. `1.1.2`) is reserved for release tagging and the `master` branch (which reflects the most recent release). On the other hand, a fourth _development_ component `-9000` is added for the not-yet-released development happening in the `develop` and _feature_ branches. The package version is updated for the next release (see below) just before the merge into `master` (from `develop` or a _release_ branch). Afterwards, `-9000` is added again to the new version for the future development. Here we assume that the most recent release is `1.0.0`, hence the version on `develop` is `1.0.0-9000`. Releases should only happen from a **stable `develop`**, possibly creating a **_release_ branch** for the release preparation, with a name of the form `release/v`, e.g. `release/v1.1.0` for a new _minor_ release. @@ -33,7 +34,7 @@ Releases should only happen from a **stable `develop`**, possibly creating a **_ - For _major_ changes: `1.0.0-9000` -> `2.0.0` - Change version number in `NEWS.md` and `DESCRIPTION` files. -(Note: for the remaining steps, a minor release with `1.1.0` will be used as an example) +(Note: for the remaining steps, a _minor_ release with `1.1.0` will be used as an example) 2. **Commit and push** all changes with the comment: `1.1.0 release preps` and `closes` lines for all issues mentioned in the `NEWS.md`, e.g. From f4a26f17deabf69916a00bb9f6f9b8bc912ebd74 Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Fri, 18 Oct 2019 12:29:49 +0200 Subject: [PATCH 10/16] Minor grammar fix. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index cc71ac2..1ee1d2c 100644 --- a/README.md +++ b/README.md @@ -42,7 +42,7 @@ SmaRP::launch_application() devtools::install_github("miraisolutions/SmaRP", "develop", build_opts = "") ``` -Note that **SmaRP** is deployed using [version-stable](https://github.com/rocker-org/rocker-versioned#readme) images from the [Rocker project](https://www.rocker-project.org/). The target environment of live app is currently bound to R 3.5.3. Therefore, the app is developed and tested with the corresponding version of R and packages, as opposed to the latest available versions. +Note that **SmaRP** is deployed using [version-stable](https://github.com/rocker-org/rocker-versioned#readme) images from the [Rocker project](https://www.rocker-project.org/). The target environment of the live app is currently bound to R 3.5.3. Therefore, the app is developed and tested with the corresponding version of R and packages, as opposed to the latest available versions. ## Details and key features From 466aea06e3fbb1bc9fb55239cb4c533dd0a05baa Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Fri, 18 Oct 2019 12:35:00 +0200 Subject: [PATCH 11/16] Removed comment about running SmaRP Docker image locally. Issue #149 created to consider that. --- README.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/README.md b/README.md index 1ee1d2c..81f5cce 100644 --- a/README.md +++ b/README.md @@ -20,13 +20,6 @@ Unlike other pension calculators, this makes results transparent, comparable, an The **SmaRP** Shiny app is [deployed](gke#readme) to Google Cloud Platform (using [Docker containers](https://www.docker.com/resources/what-container)) and can be accessed at https://mirai-solutions.ch/gallery/smarp. - The R package **SmaRP** can be installed from GitHub with From 860193654e97bf039cfe116cd348ca33af7b1dea Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Fri, 18 Oct 2019 12:35:51 +0200 Subject: [PATCH 12/16] Use remotes for install_github(). --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 81f5cce..78aa36c 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ can be accessed at https://mirai-solutions.ch/gallery/smarp. The R package **SmaRP** can be installed from GitHub with ``` r -devtools::install_github("miraisolutions/SmaRP", build_opts = "") +remotes::install_github("miraisolutions/SmaRP", build_opts = "") ``` and used to serve the app locally from R via ``` r @@ -32,7 +32,7 @@ SmaRP::launch_application() ``` **SmaRP** is developed using a [GitFlow](git-flow#readme) approach, hence the `master` branch always reflects the _latest_ [release](https://github.com/miraisolutions/SmaRP/releases) of the live app, whereas branch `develop` collects the latest delivered developments for the _next_ releases, which can be installed locally via ``` r -devtools::install_github("miraisolutions/SmaRP", "develop", build_opts = "") +remotes::install_github("miraisolutions/SmaRP", "develop", build_opts = "") ``` Note that **SmaRP** is deployed using [version-stable](https://github.com/rocker-org/rocker-versioned#readme) images from the [Rocker project](https://www.rocker-project.org/). The target environment of the live app is currently bound to R 3.5.3. Therefore, the app is developed and tested with the corresponding version of R and packages, as opposed to the latest available versions. From 0f2e728a07e126d0d3ebb481dd792cf66f8dc25d Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Fri, 18 Oct 2019 12:49:05 +0200 Subject: [PATCH 13/16] Rephrasing and refining feature branch bullet. --- git-flow/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-flow/README.md b/git-flow/README.md index b867756..047a9a4 100644 --- a/git-flow/README.md +++ b/git-flow/README.md @@ -11,8 +11,8 @@ We use a [**GitFlow**](https://nvie.com/posts/a-successful-git-branching-model/) The overall GitFlow branching system is described as follows - No work is committed and pushed directly to `master`, which is updated only as part of a [**release**](#release). -- Small (maintenance) work can be done directly in `develop`, however meaningful pieces should be developed in a dedicated **_feature_ branch** created from `develop` and associated to a GitHub issue. - - By convention, the branch name is of the form `feature/-short-lowercase-title`. This also applies to bug-fixes (see however below for hot-fixes), where a separate naming like `fix/-xyz` should be avoided (see [nvie/gitflow#24](https://github.com/nvie/gitflow/issues/24)), possibly using something like `feature/-fix-xyz` instead, e.g. `feature/142-fix-p2-interest-rate-step` for [#142](https://github.com/miraisolutions/SmaRP/issues/142). +- Small (maintenance) work can be done directly in `develop`, however meaningful pieces should be developed in a dedicated **_feature_ branch** created from `develop` and associated to a GitHub issue (``). + - By convention, the branch name is of the form `feature/-short-lowercase-title`. This also applies to bug-fixes, where a separate naming like `fix/-xyz` should be avoided (see [nvie/gitflow#24](https://github.com/nvie/gitflow/issues/24)), possibly using something like `feature/-fix-xyz` instead, e.g. `feature/142-fix-p2-interest-rate-step` for [#142](https://github.com/miraisolutions/SmaRP/issues/142). Note however that hot-fixes are treated differently, as explaiend below. - Once completed, the branch is merged back into `develop` via a pull request. - Each significant development must be mentioned as a bullet point in the top-section of [**`NEWS.md`**](../NEWS.md) before being pushed to or merged into `develop`, to serve as a change log for the next release. - **Hot-fixes** that need to be brought in asap, independently of any other pending development, are carried out in a dedicated branch (of the form `hotfix/-short-lowercase-title`) created from `master`. The branch is merged directly back to `master` as a new **_patch_ release**, and must be also merged into `develop` (or possibly an open _release_ branch). From 015f4ca8ca3f18333ae4d022ae61d402136d5b6b Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Fri, 18 Oct 2019 12:53:41 +0200 Subject: [PATCH 14/16] No custom anchor for release section. Not supporterd in GFM. --- git-flow/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/git-flow/README.md b/git-flow/README.md index 047a9a4..f719d59 100644 --- a/git-flow/README.md +++ b/git-flow/README.md @@ -6,19 +6,19 @@ We use a [**GitFlow**](https://nvie.com/posts/a-successful-git-branching-model/) branching model, where the repository holds two main **branches** with an infinite lifetime: - [**`master`**](https://github.com/miraisolutions/SmaRP/tree/master) reflects the [**latest release**](https://github.com/miraisolutions/SmaRP/releases/latest) to production, i.e. the current version of the [live app](https://mirai-solutions.ch/gallery/smarp). -- [**`develop`**](https://github.com/miraisolutions/SmaRP/tree/develop) collects all completed developments for the [**next release**](#release). +- [**`develop`**](https://github.com/miraisolutions/SmaRP/tree/develop) collects all completed developments for the [**next release**](#versioning-and-releases). The overall GitFlow branching system is described as follows -- No work is committed and pushed directly to `master`, which is updated only as part of a [**release**](#release). +- No work is committed and pushed directly to `master`, which is updated only as part of a [**release**](#versioning-and-releases). - Small (maintenance) work can be done directly in `develop`, however meaningful pieces should be developed in a dedicated **_feature_ branch** created from `develop` and associated to a GitHub issue (``). - By convention, the branch name is of the form `feature/-short-lowercase-title`. This also applies to bug-fixes, where a separate naming like `fix/-xyz` should be avoided (see [nvie/gitflow#24](https://github.com/nvie/gitflow/issues/24)), possibly using something like `feature/-fix-xyz` instead, e.g. `feature/142-fix-p2-interest-rate-step` for [#142](https://github.com/miraisolutions/SmaRP/issues/142). Note however that hot-fixes are treated differently, as explaiend below. - Once completed, the branch is merged back into `develop` via a pull request. - Each significant development must be mentioned as a bullet point in the top-section of [**`NEWS.md`**](../NEWS.md) before being pushed to or merged into `develop`, to serve as a change log for the next release. - **Hot-fixes** that need to be brought in asap, independently of any other pending development, are carried out in a dedicated branch (of the form `hotfix/-short-lowercase-title`) created from `master`. The branch is merged directly back to `master` as a new **_patch_ release**, and must be also merged into `develop` (or possibly an open _release_ branch). - -## Versioning and Releases {#release} + +## Versioning and Releases **SmaRP** uses a [**semantic versioning**](https://semver.org/) scheme bound to the version of the underlying R package. The basic versioning scheme _`major.minor.patch`_ (e.g. `1.1.2`) is reserved for release tagging and the `master` branch (which reflects the most recent release). On the other hand, a fourth _development_ component `-9000` is added for the not-yet-released development happening in the `develop` and _feature_ branches. The package version is updated for the next release (see below) just before the merge into `master` (from `develop` or a _release_ branch). Afterwards, `-9000` is added again to the new version for the future development. From ba5b9ac97b9461a0f6429f3620fc8d3d5790b7db Mon Sep 17 00:00:00 2001 From: riccardoporreca Date: Fri, 18 Oct 2019 12:57:43 +0200 Subject: [PATCH 15/16] Re-structure references. --- git-flow/README.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/git-flow/README.md b/git-flow/README.md index f719d59..31c0511 100644 --- a/git-flow/README.md +++ b/git-flow/README.md @@ -67,8 +67,6 @@ Releases should only happen from a **stable `develop`**, possibly creating a **_ ## References -* [GitFlow for GitHub](https://datasift.github.io/gitflow) by DataSift. -* [Git and GitHub](http://r-pkgs.had.co.nz/git.html) from Hadley Wickham's [R packages](http://r-pkgs.had.co.nz/). -* [Package versioning](http://r-pkgs.had.co.nz/description.html#version) from Hadley Wickham's [R packages](http://r-pkgs.had.co.nz/). -* [Releasing a package](http://r-pkgs.had.co.nz/release.html) from Hadley Wickham's [R packages](http://r-pkgs.had.co.nz/). +- DataSift: [GitFlow for GitHub](https://datasift.github.io/gitflow). +- [R packages](http://r-pkgs.had.co.nz/) by Hadley Wickham: [Git and GitHub](http://r-pkgs.had.co.nz/git.html), [Package versioning](http://r-pkgs.had.co.nz/description.html#version), [Releasing a package](http://r-pkgs.had.co.nz/release.html). From e4189d8551888eba0c5567966905e337430dff45 Mon Sep 17 00:00:00 2001 From: Roland Schmid Date: Tue, 22 Oct 2019 16:42:43 +0200 Subject: [PATCH 16/16] fixed typo --- git-flow/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-flow/README.md b/git-flow/README.md index 31c0511..5484912 100644 --- a/git-flow/README.md +++ b/git-flow/README.md @@ -12,7 +12,7 @@ The overall GitFlow branching system is described as follows - No work is committed and pushed directly to `master`, which is updated only as part of a [**release**](#versioning-and-releases). - Small (maintenance) work can be done directly in `develop`, however meaningful pieces should be developed in a dedicated **_feature_ branch** created from `develop` and associated to a GitHub issue (``). - - By convention, the branch name is of the form `feature/-short-lowercase-title`. This also applies to bug-fixes, where a separate naming like `fix/-xyz` should be avoided (see [nvie/gitflow#24](https://github.com/nvie/gitflow/issues/24)), possibly using something like `feature/-fix-xyz` instead, e.g. `feature/142-fix-p2-interest-rate-step` for [#142](https://github.com/miraisolutions/SmaRP/issues/142). Note however that hot-fixes are treated differently, as explaiend below. + - By convention, the branch name is of the form `feature/-short-lowercase-title`. This also applies to bug-fixes, where a separate naming like `fix/-xyz` should be avoided (see [nvie/gitflow#24](https://github.com/nvie/gitflow/issues/24)), possibly using something like `feature/-fix-xyz` instead, e.g. `feature/142-fix-p2-interest-rate-step` for [#142](https://github.com/miraisolutions/SmaRP/issues/142). Note however that hot-fixes are treated differently, as explained below. - Once completed, the branch is merged back into `develop` via a pull request. - Each significant development must be mentioned as a bullet point in the top-section of [**`NEWS.md`**](../NEWS.md) before being pushed to or merged into `develop`, to serve as a change log for the next release. - **Hot-fixes** that need to be brought in asap, independently of any other pending development, are carried out in a dedicated branch (of the form `hotfix/-short-lowercase-title`) created from `master`. The branch is merged directly back to `master` as a new **_patch_ release**, and must be also merged into `develop` (or possibly an open _release_ branch).