Skip to content

Commit

Permalink
Merge branch 'dev' into deploy/documentation/2024-10-09
Browse files Browse the repository at this point in the history 
* dev: (52 commits)
  Enhancement/higcharts Add description also in full screen view (#710)
  Internal/update contributing (#707)
  Internal/table of components (#712)
  Bugfix/remove deprecated prop (#706)
  Internal/Add and info box on the "Komponenter"-landing page, (#708)
  Internal/update top menu (#705)
  Internal/update footer (#699)
  Update documentation app to angular 18 (#698)
  Release/fhi-angular-components/5.0.1 (#696)
  Release/fhi-angular-highcharts/5.0.2 (#697)
  Release/fhi-angular-highcharts/5.0.1 (#695)
  Release/fhi-angular-highcharts/5.0.0 (#693)
  Release/fhi-angular-components/5.0.0 (#692)
  Update to Angular 18 in @folkehelseinstituttet/angular-highcharts (#691)
  Update to Angular 18 in @folkehelseinstituttet/angular-components (#689)
  Bugfix/highcharts: Don't set default diagram types (#688)
  Release/fhi-angular-components/4.4.2 (#683)
  Bugfix/fhi-tree-view-selection (#679)
  Add test for undefined in FhiTreeViewNavigationComponent (#680)
  Release/fhi-angular-highcharts/4.4.0 (#681)
  ...
  • Loading branch information
Bernt Andersen committed Oct 9, 2024
2 parents 2f48457 + bfa4965 commit 6b974ab
Show file tree
Hide file tree
Showing 176 changed files with 5,570 additions and 5,644 deletions.
1 change: 1 addition & 0 deletions .gitignore
View file
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,7 @@ speed-measure-plugin*.json
*.launch
.settings/
*.sublime-workspace
/.vs

# IDE - VSCode
.vscode/*
Expand Down
113 changes: 74 additions & 39 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,8 @@ So you're thinking about contributing to **Fhi.Frontend.Demo**, and or its submo
- [Feature branches](#feature-branches-1)
- [Release branches for library projects](#release-branches-for-library-projects)
- [Release a patch to older version in a library project](#release-a-patch-to-older-version-in-a-library-project)
- [Release branches for the Fhi.Frontend.Demo app](#release-branches-for-the-fhifrontenddemo-app)
- [After release is done](#after-release-is-done)
- [Deploy branches for the documentation site](#deploy-branches-for-the-documentation-site)
- [Coding conventions](#coding-conventions)
- [CSS/SASS](#csssass)
- [CSS architecture](#css-architecture)
Expand Down Expand Up @@ -73,8 +74,8 @@ It is also a good idea to add a comment to an issue that you are working on to l

### Workflows

_These are just examples. Feel free to find workflows that suites you._
_For more info about git submodules see: [https://git-scm.com/book/en/v2/Git-Tools-Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules)_
*These are just examples. Feel free to find workflows that suites you.*
*For more info about git submodules see: [https://git-scm.com/book/en/v2/Git-Tools-Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules)*

#### How to work on Fhi.Frontend.Style and Fhi.Frontend.Demo

Expand Down Expand Up @@ -122,16 +123,29 @@ You can also use `ng generate directive|pipe|service|class|guard|interface|enum

##### Release branches

>**Before creating a release branch**
>
>- Check that the CHANGELOG.md is updated, and has "Unreleased" as latest version.
>
> If not; create a branch, fix, and create a new pull request.
>
>**If everything is OK; create a release branch**
>
>- When creating a release branch, follow the instructions below to the letter!
1. Create a new branch from `main`.
2. Name it `release/x.x.x`, where `x.x.x` is the version you're releasing.
3. Change text `# Unreleased` to `# x.x.x` i `CHANGELOG.md`
3. Update CHANGELOG
1. Change text `# Unreleased` to `# x.x.x` i CHANGELOG.md.
2. Change the date below the version number to today.
3. Check that all descriptions have a link to the PR at the end of the line.
4. Run `npm version [patch, minor, major]` to upgrade `package.json` and automatically create a new commit.
5. Push release branch and create pull request from release branch into `main`
6. After approved review, squash and merge to `main` (deploy), delete the release branch for the previous release, but keep the latest release branch.
5. Push release branch and create pull request from release branch into main.
6. After approved review, squash and merge to main (deploy), delete the release branch for the previous release, but keep the latest release branch.

#### Fhi.Frontend.Demo, including library projects

_A library project is an Angular concept for organising code that are going to be made into a npm package. A library project is defined in `./angular.json`, and the files are located in `./projects/fhi-[project]`_
*A library project is an Angular concept for organising code that are going to be made into a npm package. A library project is defined in `./angular.json`, and the files are located in `./projects/fhi-[project]`*

##### Feature branches

Expand All @@ -145,7 +159,7 @@ _A library project is an Angular concept for organising code that are going to b
>
>- Check that all peerDependencies are updated
>- Check that `@folkehelseinstituttet/*` is already released if listed in peerDependencies
>- Check that the dependency matrix is updated, and has "Unreleased" as latest version.
>- Check that the dependency matrix still is correct, and if it's updated since last release, that it has "Unreleased" as latest version.
>- Check that the CHANGELOG.md is updated, and has "Unreleased" as latest version.
>
> If one or more of the checks above is not OK; create a branch, fix, and create a new pull request.
Expand All @@ -156,42 +170,63 @@ _A library project is an Angular concept for organising code that are going to b
1. Create a new branch from `dev`.
2. Name it `release/fhi-[project]/x.x.x`, where `x.x.x` is the version you're releasing.
3. Update the following and commit:
1. text `# Unreleased` to `# x.x.x` in the CHANGELOG for the project: `./projects/fhi-[project]/CHANGELOG.md`
2. text `Unreleased` to `x.x.x` in the dependency matrix for the project: `./projects/fhi-[project]/README.md` (if a new line was added).
3. version in `./projects/fhi-[project]/package.json` to `x.x.x` manually.
>_It's cumbersome to use `npm version` since `package.json` is in another directory than the git directory. And since there is no `package-lock.json`, and no need for a tag in the current workflow, doing it manually is faster. A better, and more automated, solution may come in the future._
4. Create PR into `dev` from `release/fhi-[project]/x.x.x`, and when approved, make sure commit message is _Release/fhi-[project]/x.x.x_, and then merge (ie. deploy).
>_NB! Automated release job only runs if `Release/fhi-[project]/` is present in commit message since this isn't a release for everything in the repo, just a particular library._
3. Update CHANGELOG
1. Change text `# Unreleased` to `# x.x.x` i CHANGELOG.md.
2. Change the date below the version number to today.
3. Check that all descriptions have a link to the PR at the end of the line.
4. Update text `Unreleased` to `x.x.x` in the dependency matrix for the project: `./projects/fhi-[project]/README.md` (if a new line was added).
5. Update version in `./projects/fhi-[project]/package.json` to `x.x.x` manually.
>*It's cumbersome to use `npm version` since `package.json` is in another directory than the git directory. And since there is no `package-lock.json`, and no need for a tag in the current workflow, doing it manually is faster. A better, and more automated, solution may come in the future.*
6. Create PR into `dev` from `release/fhi-[project]/x.x.x`, and when approved, make sure commit message is *Release/fhi-[project]/x.x.x*, and then merge (ie. deploy).

>*NB! Automated release job only runs if `Release/fhi-[project]/` is present in commit message since this isn't a release for everything in the repo, just a particular library.*
##### Release a patch to older version in a library project

Almost same procedure as described under [Release branches for library projects](#release-branches-for-library-projects), but there are some minor differences:

1. Create a new branch from `fhi-[project]/vx`, where `X` is the major version you're patching (remember ref. to correct git submodule).
2. Name it `release/fhi-[project]/x.x.x`, where `x.x.x` is the version you're releasing.
3. Update the following and commit:
1. Add `# x.x.x` in beginning of the CHANGELOG for the project: `./projects/fhi-[project]/CHANGELOG.md`
2. Add and extra `#` to the previous version number.
3. **NB!** when updating version in `./projects/fhi-[project]/package.json` to `x.x.x`, ALSO update `publishConfig.tag` to `v[x]` where `[x]` is the major version you're patching.
4. Create PR into `fhi-[project]/vx` from `release/fhi-[project]/x.x.x`, and when approved, make sure commit message is _Release/fhi-[project]/x.x.x_, and then merge (ie. deploy).
5. Create PR into `dev` from `release/fhi-[project]/x.x.x` to merge relevant changes from the patch back into `dev`, and when approved, make sure commit message is _Release/fhi-[project]/x.x.x_, and then merge AND delte branch `release`.
>_NB! This PR will probably have conflicts, so just merge `dev` into `release` before creating PR, and fix conflicts. Ask someone if in doubt about any conflicts, but here are a few things to remember when merging:_
>1. **ALWAYS** merge changes to CHANGELOG (in chronological order based on date, not version)
>2. Sometimes merge changes to the code
>3. **NEVER** merge any changes to `publishConfig.tag` in `./projects/fhi-[project]/package.json`
>4. Remember correct git submodule ref.
##### Release branches for the Fhi.Frontend.Demo app

There is no need for a release branch, since the branch `dev` represents the "truth". Therefore we do not create a pull request with main as base either, we just:

1. Check that `package.json` is up to date with the latest versions of `@folkehelseinstituttet/style`
- If not: create a feature branch named `enhancement/update-dependencies`, and fix it.
- Create PR, and merge `enhancement/update-dependencies` to `dev` when approved.
2. Merge `main` into `dev` and fix merge conflicts if any.
3. Merge `dev` into `main`
4. Push to origin (which will trigger the release)
1. If it doesn't already exist, create a branch from `dev` called `fhi-[project]/vx`, where `X` is the major version you're patching.
2. Create a new branch from `fhi-[project]/vx`, and fix bug (remember ref. to correct git submodule).
3. Merge bugfix back to `fhi-[project]/vx`
4. Create a new branch from `fhi-[project]/vx`.
5. Name it `release/fhi-[project]/x.x.x`, where `x.x.x` is the version you're releasing.
6. Update CHANGELOG
1. Change text `# Unreleased` to `# x.x.x` i CHANGELOG.md.
2. Change the date below the version number to today.
3. Check that all descriptions have a link to the PR at the end of the line.
7. Update text `Unreleased` to `x.x.x` in the dependency matrix for the project: `./projects/fhi-[project]/README.md` (if a new line was added).
8. Update version in `./projects/fhi-[project]/package.json` to `x.x.x` manually.
9. **NB! Also update `publishConfig.tag` to `v[x]` where `[x]` is the major version you're patching.**
10. Create PR into `fhi-[project]/vx` from `release/fhi-[project]/x.x.x`, and when approved, make sure commit message is *Release/fhi-[project]/x.x.x*, and then merge (ie. deploy).

###### After release is done

Create PR into `dev` from `release/fhi-[project]/x.x.x` to merge relevant changes from the patch back into `dev`, and when approved, make sure commit message is *Changes from patch @folkehelseinstituttet/angular-[project]/v/x.x.x*, and then merge and delete branch `release`.

>*NB! This PR will probably have conflicts, so just merge `dev` into `release` before creating PR, and fix conflicts. Ask someone if in doubt about any conflicts, but here are a few things to remember when merging:*
>
>1. **ALWAYS** merge changes to CHANGELOG (in chronological order based on date, not version), but change `# x.x.x` to `Unreleased`.
>2. Merge relevant changes to the code.
>3. **NEVER** merge any changes to `./projects/fhi-[project]/package.json`.
>4. Remember correct git submodule ref.
##### Deploy branches for the documentation site

>**Before creating a deploy branch**
>
>- Check that `package.json` is up to date with the latest versions of `@folkehelseinstituttet/style`.
>
> *PS. The angular-packages are not listet in `package.json` since they are always latest, buildt from source, not downloaded from npm registry unless you run script `build-prod`*
>
> If not; create a branch, fix, and create a new pull request.
>
> **If everything is OK; create a release branch**
>
>- When creating a release branch, follow the instructions below to the letter!
1. Create a new branch from `main`, and call it `deploy/documentation-[yyy-mm-dd]`.
2. Merge `dev` into `deploy/documentation-[yyy-mm-dd]` and fix merge conflicts if any.
3. Create PR into `main` from `deploy/documentation-[yyy-mm-dd]`, and when approved, merge (ie. deploy).

## Coding conventions

Expand Down
2 changes: 1 addition & 1 deletion Fhi.Frontend.Style
Submodule Fhi.Frontend.Style updated 3 files
+2 −2 CHANGELOG.md
+2 −2 package-lock.json
+1 −1 package.json
Loading

0 comments on commit 6b974ab

Please sign in to comment.