Skip to content
Snippets Groups Projects
Verified Commit 4b5d06d4 authored by Volker Schukai's avatar Volker Schukai :alien:
Browse files

feat: initialize

parent afdc4767
No related branches found
No related tags found
No related merge requests found
Pipeline #30702 failed
Showing
with 1097 additions and 70 deletions
{{ range .Versions }}
## {{ if .Tag.Previous }}[{{ .Tag.Name }}]{{ else }}{{ .Tag.Name }}{{ end }} - {{ datetime "2006-01-02" .Tag.Date }}
{{ range .CommitGroups -}}
### {{ .Title }}
{{ range .Commits -}}
- {{ if .Scope }}**{{ .Scope }}:** {{ end }}{{ .Subject }}
{{ end }}{{ end -}}
{{ end -}}
style: gitlab
template: CHANGELOG.tpl.md
info:
title: CHANGELOG
repository_url: https://gitlab.schukai.com/oss/libraries/go/documents/pdf
options:
commits:
filters:
Type:
- feat
- fix
- doc
- refactor
- perf
- test
- chore
## deprecated types and typos
- docs
- documentation
- feat
- added
- add
- bugfix
- revert
- update
- updates
- change
- changed
commit_groups:
title_maps:
feat: Add Features
fix: Bug Fixes
doc: Documentation
refactor: Code Refactoring
perf: Performance Improvements
test: Tests
## Chore is used for all other changes that don't fit in the other categories
chore: Changes
## deprecated types and typos
docs: Documentation
documentation: Documentation
added: Add Features
add: Add Features
bugfix: Bug Fixes
revert: Reverts
update: Changes
updates: Changes
change: Changes
changed: Changes
header:
pattern: "^(\\w*)(?:\\(([\\w\\$\\.\\-\\*\\s]*)\\))?\\:\\s(.*)$"
pattern_maps:
- Type
- Scope
- Subject
notes:
keywords:
- BREAKING CHANGE
.envrc 0 → 100644
watch_file ./flake.nix ./nix/scripts/*.nix ./nix/config/*.nix ./nix/packages/*.nix
use flake
\ No newline at end of file
# Created by https://www.toptal.com/developers/gitignore/api/intellij,go
# Edit at https://www.toptal.com/developers/gitignore?templates=intellij,go
### Go ###
# If you prefer the allow list template instead of the deny list, see community template:
# https://github.com/github/gitignore/blob/main/community/Golang/Go.AllowList.gitignore
#
# Binaries for programs and plugins
*.exe
*.exe~
*.dll
*.so
*.dylib
# Test binary, built with `go test -c`
*.test
# Output of the go coverage tool, specifically when used with LiteIDE
*.out
# Dependency directories (remove the comment below to include it)
# vendor/
# Go workspace file
go.work
### Go Patch ###
/vendor/
/Godeps/
### Intellij ###
# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebStorm and Rider
# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839
# User-specific stuff
.idea/**/workspace.xml
.idea/**/tasks.xml
.idea/**/usage.statistics.xml
.idea/**/dictionaries
.idea/**/shelf
# AWS User-specific
.idea/**/aws.xml
# Generated files
.idea/**/contentModel.xml
# Sensitive or high-churn files
.idea/**/dataSources/
.idea/**/dataSources.ids
.idea/**/dataSources.local.xml
.idea/**/sqlDataSources.xml
.idea/**/dynamic.xml
.idea/**/uiDesigner.xml
.idea/**/dbnavigator.xml
# Gradle
.idea/**/gradle.xml
.idea/**/libraries
# Gradle and Maven with auto-import
# When using Gradle or Maven with auto-import, you should exclude module files,
# since they will be recreated, and may cause churn. Uncomment if using
# auto-import.
# .idea/artifacts
# .idea/compiler.xml
# .idea/jarRepositories.xml
# .idea/modules.xml
# .idea/*.iml
# .idea/modules
# *.iml
# *.ipr
# CMake
cmake-build-*/
# Mongo Explorer plugin
.idea/**/mongoSettings.xml
# File-based project format
*.iws
# IntelliJ
out/
# mpeltonen/sbt-idea plugin
.idea_modules/
# JIRA plugin
atlassian-ide-plugin.xml
# Cursive Clojure plugin
.idea/replstate.xml
# SonarLint plugin
.idea/sonarlint/
# Crashlytics plugin (for Android Studio and IntelliJ)
com_crashlytics_export_strings.xml
crashlytics.properties
crashlytics-build.properties
fabric.properties
# Editor-based Rest Client
.idea/httpRequests
# Android studio 3.1+ serialized cache file
.idea/caches/build_file_checksums.ser
### Intellij Patch ###
# Comment Reason: https://github.com/joeblau/gitignore.io/issues/186#issuecomment-215987721
# *.iml
# modules.xml
# .idea/misc.xml
# *.ipr
# Sonarlint plugin
# https://plugins.jetbrains.com/plugin/7973-sonarlint
.idea/**/sonarlint/
# SonarQube Plugin
# https://plugins.jetbrains.com/plugin/7238-sonarqube-community-plugin
.idea/**/sonarIssues.xml
# Markdown Navigator plugin
# https://plugins.jetbrains.com/plugin/7896-markdown-navigator-enhanced
.idea/**/markdown-navigator.xml
.idea/**/markdown-navigator-enh.xml
.idea/**/markdown-navigator/
# Cache file creation bug
# See https://youtrack.jetbrains.com/issue/JBR-2257
.idea/$CACHE_FILE$
# CodeStream plugin
# https://plugins.jetbrains.com/plugin/12206-codestream
.idea/codestream.xml
# Azure Toolkit for IntelliJ plugin
# https://plugins.jetbrains.com/plugin/8053-azure-toolkit-for-intellij
.idea/**/azureSettings.xml
# End of https://www.toptal.com/developers/gitignore/api/intellij,go
# Devenv
.devenv*
devenv.local.nix
# direnv
.direnv
# pre-commit
.pre-commit-config.yaml
/Session.vim
variables:
NIXPKGS_ALLOW_UNFREE: "1"
NIXPKGS_ALLOW_INSECURE: "1"
GIT_DEPTH: 10
GIT_SUBMODULE_STRATEGY: normal
GIT_SUBMODULE_DEPTH: 1
stages:
- test
- release
before_script:
- git config --global user.email "${GITLAB_USER_EMAIL}"
- git config --global user.name "${GITLAB_USER_NAME:-"Gitlab CI"}"
- git config --global credential.helper '!f() { echo "username=gitlab-ci-token"; echo "password=${CI_JOB_TOKEN}"; }; f'
- git config --global pull.rebase true
- git config --global http.sslVerify "false"
after_script:
- nix develop .#gitlab --command clean-up
tests:
stage: test
tags:
- nixos-gen3
script:
- nix develop .#gitlab --command run-ci-tests
release:
stage: release
tags:
- nixos-gen3
script:
- nix develop .#gitlab --command release
when: on_success
rules:
- if: $CI_COMMIT_BRANCH == "master"
\ No newline at end of file
# RFC: [Titel deines Vorschlags]
Kurze Beschreibung des Inhalts und Ziels dieses RFC.
### Zweig:
In welchem Zweig ist/wird der RFC implementiert?
## Reviewer
Liste Personen oder Teams auf, die für das Review dieses RFC verantwortlich sind.
- [ ] @reviewer1
## Hintergrund
Erläutere den Kontext und die Probleme, die zur Erstellung dieses RFC geführt haben.
## Grundlegende Beispiele
Biete einfache Beispiele, die die vorgeschlagenen Änderungen veranschaulichen.
## Motivation
Beschreibe, warum diese Änderung notwendig ist. Welche Probleme werden gelöst? Was sind die Vorteile?
## Vorgeschlagene Lösung
Detaillierte Beschreibung der vorgeschlagenen Features und Funktionen.
## Detailliertes Design und Umsetzung
Erkläre technische Details, Implementierungsschritte und wie die Lösung integriert werden soll.
## Roadmap und benötigte Ressourcen
Skizziere die geplanten Schritte zur Implementierung und liste benötigte Ressourcen auf.
## Vor- und Nachteile / Einschränkungen
Diskutiere die möglichen Nachteile oder Limitationen des Vorschlags sowie die Risiken.
## Alternativen
Stelle andere überlegte Lösungen vor und erkläre, warum sie verworfen oder nicht berücksichtigt wurden.
## Neue und geänderte Konfigurationswerte
- **Neue Werte**
- **Geänderte Werte**
- **Beispielkonfigurationen**
## Schulungsmaßnahmen
Beschreibe, wie du planst, das Team und die Nutzer über die Änderungen zu informieren und zu schulen.
## Legal und Privacy
Beschreibe die Auswirkungen auf rechtliche und Datenschutzaspekte.
## Risiken
Beschreibe mögliche Risiken und wie sie minimiert werden können.
## Offene Fragen
Diskutiere Aspekte, die noch geklärt werden müssen und bei denen Feedback erforderlich ist.
## Nicht betroffene Funktionalität
Identifiziere Bereiche, die durch diesen RFC nicht beeinflusst werden.
## Zukünftiger Anwendungsbereich
Betrachte zukünftige Erweiterungen oder Verbesserungen, die auf diesem Vorschlag aufbauen könnten.
## Patches und Tests
- **Patch-Verfügbarkeit**
- **Testpläne**
## Implementierung
Nachdem das Projekt implementiert wurde, sollte dieser Abschnitt Folgendes enthalten:
1. Die Version(en), in die das Feature eingefügt wurde.
2. Einen Link zu den entsprechenden Git-Commits.
3. Einen Link zum Handbuch-Eintrag für das Feature.
4. Einen Link zum Abschnitt mit den Sprachspezifikationen (falls vorhanden).
## Referenzen
Verweise auf relevante externe Diskussionen, Dokumente oder andere RFCs.
## Abgelehnte Features
Erläutere, welche Features vorgeschlagen, aber nicht angenommen wurden, und warum.
# Gedanken und Ideen
Beschreibe Deine Gedanken und Ideen, die Du mit anderen teilen möchtest. Dieses Template ist für
allgemeine Diskussionen und Brainstorming gedacht. Wenn Du eine spezifische Änderung oder ein neues
Feature vorschlagen möchtest, verwende bitte das [RFC-Template](./rfc.md).
# Default ignored files
/shelf/
/workspace.xml
# Editor-based HTTP Client requests
/httpRequests/
# Datasource local storage ignored files
/dataSources/
/dataSources.local.xml
<component name="ProjectCodeStyleConfiguration">
<state>
<option name="PREFERRED_PROJECT_CODE_STYLE" value="Default" />
</state>
</component>
\ No newline at end of file
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="ProjectRootManager" version="2" languageLevel="JDK_21" default="true" project-jdk-name="21 (3)" project-jdk-type="JavaSDK">
<output url="file://$PROJECT_DIR$/out" />
</component>
<component name="accountSettings">
<option name="activeProfile" value="profile:default" />
<option name="activeRegion" value="eu-west-1" />
<option name="recentlyUsedProfiles">
<list>
<option value="profile:default" />
</list>
</option>
<option name="recentlyUsedRegions">
<list>
<option value="eu-west-1" />
</list>
</option>
</component>
</project>
\ No newline at end of file
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="ProjectModuleManager">
<modules>
<module fileurl="file://$PROJECT_DIR$/.idea/pdf.iml" filepath="$PROJECT_DIR$/.idea/pdf.iml" />
</modules>
</component>
</project>
\ No newline at end of file
<?xml version="1.0" encoding="UTF-8"?>
<module type="JAVA_MODULE" version="4">
<component name="Go" enabled="true" />
<component name="NewModuleRootManager" inherit-compiler-output="true">
<exclude-output />
<content url="file://$MODULE_DIR$" />
<orderEntry type="inheritedJdk" />
<orderEntry type="sourceFolder" forTests="false" />
</component>
</module>
\ No newline at end of file
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="VcsDirectoryMappings">
<mapping directory="" vcs="Git" />
</component>
</project>
\ No newline at end of file
<a name="v1.14.0"></a>
## [v1.14.0] - 2022-10-24
### Add Features
- feat add path value [#1](https://gitlab.schukai.com/oss/libraries/go/application/configuration/issues/1)
### Changes
- chore add licenses
<a name="v1.13.0"></a>
## [v1.13.0] - 2022-10-24
### Bug Fixes
- fix allow override
<a name="v1.12.0"></a>
## [v1.12.0] - 2022-10-23
### Add Features
- feat new merge method
### Changes
- chore add licenses
<a name="v1.11.4"></a>
## [v1.11.4] - 2022-10-23
### Bug Fixes
- fix the prefix of the env function now works
<a name="v1.11.3"></a>
## [v1.11.3] - 2022-10-23
### Bug Fixes
- fix watchlist was empty
<a name="v1.11.2"></a>
## [v1.11.2] - 2022-10-23
### Bug Fixes
- fix deleted files must not be removed from the watch list
<a name="v1.11.1"></a>
## [v1.11.1] - 2022-10-23
### Bug Fixes
- fix monitor directories not files
<a name="v1.11.0"></a>
## [v1.11.0] - 2022-10-23
### Add Features
- feat error handler and changed update handler
- feat inform enventhandler about an error that has occurred
- feat new ChangeEventHandler struct
### Bug Fixes
- fix protect access to the config
### Changes
- chore licenses
### Code Refactoring
- refactor assign file list
<a name="v1.10.0"></a>
## [v1.10.0] - 2022-10-17
### Bug Fixes
- fix panic is format is nil
<a name="v1.9.0"></a>
## [v1.9.0] - 2022-10-17
### Add Features
- feat add HasOnChangeHook and RemoveOnChangeHook
<a name="v1.8.0"></a>
## [v1.8.0] - 2022-10-17
### Add Features
- feat add the posibility to recognise the filetype, add HasFile and RemoveFile
<a name="v1.7.1"></a>
## [v1.7.1] - 2022-10-15
### Bug Fixes
- fix copy values from xflags
<a name="v1.7.0"></a>
## [v1.7.0] - 2022-10-14
### Bug Fixes
- fix use wrong struct
<a name="v1.6.0"></a>
## [v1.6.0] - 2022-10-14
### Add Features
- feat implement the copyable interface of xflags
<a name="v1.5.0"></a>
## [v1.5.0] - 2022-10-14
### Add Features
- feat implement the copyable interface
<a name="v1.4.3"></a>
## [v1.4.3] - 2022-10-07
### Changes
- chore change license things
<a name="v1.4.2"></a>
## [v1.4.2] - 2022-10-07
### Changes
- chore change license things
- chore change license things
<a name="v1.4.1"></a>
## [v1.4.1] - 2022-10-06
### Changes
- chore add licenses
<a name="v1.4.0"></a>
## [v1.4.0] - 2022-10-05
### Bug Fixes
- fix settings must be exported
### Changes
- chore add license file
<a name="v1.3.0"></a>
## [v1.3.0] - 2022-09-18
### Code Refactoring
- refactor error functions
<a name="v1.2.0"></a>
## [v1.2.0] - 2022-09-18
### Changes
- chore add git-chglog tool and update makefile
<a name="v1.1.0"></a>
## [v1.1.0] - 2022-09-18
### Changes
- change api HasError() to HasErrors() as it is more logical
<a name="v1.0.1"></a>
## [v1.0.1] - 2022-09-18
### Bug Fixes
- bugfix wrong return value of function newUnsupportedReflectKindError
<a name="v1.0.0"></a>
## v1.0.0 - 2022-09-18
[v1.14.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.13.0...v1.14.0
[v1.13.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.12.0...v1.13.0
[v1.12.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.11.4...v1.12.0
[v1.11.4]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.11.3...v1.11.4
[v1.11.3]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.11.2...v1.11.3
[v1.11.2]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.11.1...v1.11.2
[v1.11.1]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.11.0...v1.11.1
[v1.11.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.10.0...v1.11.0
[v1.10.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.9.0...v1.10.0
[v1.9.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.8.0...v1.9.0
[v1.8.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.7.1...v1.8.0
[v1.7.1]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.7.0...v1.7.1
[v1.7.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.6.0...v1.7.0
[v1.6.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.5.0...v1.6.0
[v1.5.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.4.3...v1.5.0
[v1.4.3]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.4.2...v1.4.3
[v1.4.2]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.4.1...v1.4.2
[v1.4.1]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.4.0...v1.4.1
[v1.4.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.3.0...v1.4.0
[v1.3.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.2.0...v1.3.0
[v1.2.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.1.0...v1.2.0
[v1.1.0]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.0.1...v1.1.0
[v1.0.1]: https://gitlab.schukai.com/oss/libraries/go/application/configuration/compare/v1.0.0...v1.0.1
# Contributing to schukai GmbH Projects
## Code of Conduct
Be a human, not an asshole. Common sense and basic human decency apply.
## Getting Started
### Setting up the Project
1. Fork the project on GitLab.
2. Clone your fork locally. Replace `[your-username]` with your GitLab username and `[project-name]` with the actual project name:
```bash
git clone $(git config --get remote.origin.url)
```
3. Add the upstream repository. Replace `[original-username]` and `[project-name]` with the original repository's username and project name:
```bash
git remote add upstream https://gitlab.schukai.com/[original-username]/[project-name].git
```
### Making Changes
1. Create a new branch:
```bash
git checkout -b new-feature-branch
```
2. Make your changes.
3. Commit your changes:
```bash
git commit -m "Description of change"
```
### Submitting a Merge Request
1. Push your changes to your fork:
```bash
git push origin new-feature-branch
```
2. Navigate to the original project repository on `gitlab.schukai.com`.
3. Open a Merge Request and provide a clear description of the changes.
## Coding Guidelines
- Follow the coding style used in the project.
- Write unit tests for new features.
- Ensure that all tests pass before submitting a Merge Request.
## Reporting Issues
If you find an issue, please create a new issue on `gitlab.schukai.com`.
## Additional Resources
- [GitLab Flow](https://docs.gitlab.com/ee/topics/gitlab_flow.html)
- [GitLab Merge Request Guidelines](https://docs.gitlab.com/ee/user/project/merge_requests/)
Thank you for your contribution!
LICENSE 0 → 100644
Copyright (C) 2023 schukai GmbH
This library is available under the AGPL-3.0
<https://choosealicense.com/licenses/agpl-3.0/>
license for open-source projects. See above for
the full license text.
For commercial use, please reach out to us
at sales@schukai.com.
All rights reserved.
AGPL-3.0 License
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published
by the Free Software Foundation, either version 3 of the License.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
# PDF # PDF
## What does this library?
This library provides a simple way to work with PDF files in Go.
## Getting started It supports:
To make it easy for you to get started with GitLab, here's a list of recommended next steps. - [x] Boolean objects
- [x] Number objects
- [x] String literals
- [x] String hexadecimals
- [ ] Name objects
- [ ] Array objects
- [ ] Dictionary objects
- [ ] Stream objects
- [ ] Indirect objects
- [ ] Null objects
-
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)! Not supported:
## Add your files - [ ] Encrypted PDFs
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files ## Installation
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
```shell
go get gitlab.schukai.com/oss/libraries/go/documents/pdf
``` ```
cd existing_repo
git remote add origin https://gitlab.schukai.com/oss/libraries/go/documents/pdf.git
git branch -M master
git push -uf origin master
```
## Integrate with your tools
- [ ] [Set up project integrations](https://gitlab.schukai.com/oss/libraries/go/documents/pdf/-/settings/integrations)
## Collaborate with your team
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
- [ ] [Set auto-merge](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
## Test and Deploy
Use the built-in continuous integration in GitLab.
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
***
# Editing this README
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template. ## Contributing
## Suggestions for a good README
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
## Name
Choose a self-explaining name for your project.
## Description
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
## Badges
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
## Visuals Merge requests are welcome. For major changes, please open an issue first to discuss what
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method. you would like to change. **Please make sure to update tests as appropriate.**
## Installation Versioning is done with [SemVer](https://semver.org/).
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection. Changelog is generated with [git-chglog](https://github.com/git-chglog/git-chglog#git-chglog)
## Usage Commit messages should follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README. Messages are started with a type, which is one of the following:
## Support - **feat**: A new feature
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc. - **fix**: A bug fix
- **doc**: Documentation only changes
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **perf**: A code change that improves performance
- **test**: Adding missing or correcting existing tests
- **chore**: Other changes that don't modify src or test files
## Roadmap The footer would be used for a reference to an issue or a breaking change.
If you have ideas for releases in the future, it is a good idea to list them in the README.
## Contributing A commit that has a footer `BREAKING CHANGE:`, or appends a ! after the type/scope,
State if you are open to contributions and what your requirements are for accepting them. introduces a breaking API change (correlating with MAJOR in semantic versioning).
A BREAKING CHANGE can be part of commits of any type.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self. the following is an example of a commit message:
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser. ```text
feat: add 'extras' field
## Authors and acknowledgment ```
Show your appreciation to those who have contributed to the project.
## License ## License
For open source projects, say how it is licensed.
## Project status This library is available under the [AGPL-3.0](https://choosealicense.com/licenses/agpl-3.0/)
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers. license for open-source projects. For commercial use, please reach out to us
at [sales@schukai.com](mailto:sales@schukai.com).
\ No newline at end of file
File added
File added
File added
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment