You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`main` | Contains the latest state of the repository
57
-
`v{version_number}-RC{rc_number}` | A state on which the working group agreed on as a release candidate but which is missing the approval by the OMP.
58
-
`v{version_number}` | A release of the respective version which is approved by the working group and the OMP.
59
-
`feature/#{issue_number}-{feature_name}` | Contains the development on a specific feature and is intended to be merged back into the `main` branch as soon as possible. Note, that it is recommended for contributors to create and develop feature branches in a personal fork and not the upstream repository.
60
-
`bug/#{issue_number}-{bug_name}` | Contains the development of (usually smaller) changes in files of the repository that do not introduce new functionality but fix mistakes, errors or inconsistencies. These branches should be merged back into the `main`branch as soon as possible.
`to be discussed` | Involvement and Discussion in one of the `working group` meetings are needed.
160
-
`request for information` | The `working group` or the `maintainers` are requesting further information from the creator of the `Issue` or `PR`. If for a pre-defined time no information is received, then the `Issue` or `PR` can be closed.
161
-
`approved` | Has been discussed and approved in the `working group`.
162
-
`not accepted` | Has been discussed in the `working group` with the decision to close this issue.
163
-
164
-
### PR or Issue Discussion and Decision
165
-
166
-
* You can provide comments to any `PR` or `Issue` via the comment function in GitHub
167
-
* If no further involvement from the working group is required, a `maintainer` may merge a `PR`.
168
-
This mostly applies to bug fixes and non-API-breaking changes.
169
-
A `PR` for a bug fix has to reference an issue of type `Bug Report`.
170
-
* The `maintainers` may assign the label `to be discussed` to a proposal when further involvement from
171
-
the `working group` is required. This then triggers the following steps:
172
-
1. The `Chair` of the `working group` puts the proposal up for discussion in one of the next `working group`
173
-
meetings.
174
-
2. The `working group` then uses Consensus Decision-Making with one of the outcomes listed below.
175
-
3. The label `to be discussed` is removed.
176
-
177
-
| Decision | Next Steps |
178
-
| ------ | ------- |
179
-
|`Approved`| The `Issue` or the `PR` gets the label `approved`. In the case of a `PR`, the `maintainers` merge the respective `PR`. |
180
-
| `Discussion`| The `Issue` or the `PR` get the label `request for information`.
181
-
|`Close`| The `Issue` or the `PR` are closed and get the label `not accepted`. |
182
-
183
-
* If the `working group` or the `maintainers` feel that further information is required to explain a `PR` or an `Issue`,
184
-
they may request this information through the comment section of the `PR` or `Issue` and assign the label
185
-
`request for information`. The `maintainers` may close the issue if no answer is received after a pre-defined time.
186
-
187
-
Note, that merging a `PR` leads to the closing of the `Issue` if it is linked in the `PR`.
188
-
189
-
### Review Checklist
190
-
191
-
The following checklist can be seen as a basis for performing reviews on new `PRs`:
192
-
193
-
-[ ] brief and useful commit messages
194
-
-[ ] code convention is followed
195
-
-[ ] the contribution matches to the linked issue and the description of the PR
196
-
-[ ] provide clear documentation of new features (if applicable)
197
-
-[ ] outline added third party dependencies
198
-
199
-
### Commit Messages
200
-
201
-
Separate the subject from the body with a blank line because the subject line is shown in the Git history and should
202
-
summarize the commit body.
203
-
Use the body to explain what and why with less focus on the details of the how.
204
-
This [blog post](https://chris.beams.io/posts/git-commit/#seven-rules) has more tips and details.
205
-
Before you push your commits to a repository, you should squash your commits into one or more logical units of work,
206
-
e.g.,
207
-
you should organize a new feature in a single commit.
109
+
## Commit Messages
110
+
111
+
Separate the subject from the body with a blank line because the subject line is shown in the Git
112
+
history and should summarize the commit body. Use the body to explain what and why with less focus
113
+
on the details of the how. This [blog post](https://chris.beams.io/posts/git-commit/#seven-rules)
114
+
has more tips and details. Before you push your commits to a repository, you should squash your
115
+
commits into one or more logical units of work, e.g., you should organize a new feature in a single
116
+
commit.
208
117
209
118
## License Headers & Licensing
210
119
211
-
All files contributed require headers - this will ensure the license and copyright clearing at the end. Also, all
212
-
contributions must have the same license as the source.
213
-
The header should follow the following template:
120
+
All files contributed require headers - this will ensure the license and copyright clearing at the
121
+
end. Also, all contributions must have the same license as the source. The header should follow the
122
+
following template:
214
123
215
124
```
216
125
/*
@@ -228,43 +137,29 @@ The header should follow the following template:
228
137
*/
229
138
```
230
139
231
-
When using the template, one must replace "{NAME OF COMPANY X}" with the name of the involved companies and "{YEAR}"
232
-
with the year of the contribution. For each involved company you need a new line starting with "Copyright" as outlined
233
-
in the example.
140
+
When using the template, one must replace "{NAME OF COMPANY X}" with the name of the involved
141
+
companies and "{YEAR}" with the year of the contribution. For each involved company you need a new
142
+
line starting with "Copyright" as outlined in the example.
234
143
235
-
The example is taken from a Typescript class file. If your file is of another type you may have to adapt the comment
236
-
syntax
237
-
accordingly.
144
+
The example is taken from a Java source file. If your file is of another type you may have to adapt
145
+
the comment syntax accordingly.
238
146
239
-
If you use third-party content (e.g., import / include ...), you are required to list each third-party content
240
-
explicitly with its version number in the documentation and your pull-request comment.
241
-
Please also check used third party material for license compatibility with the MPL-2.0.
147
+
If you use third-party content (e.g., import / include ...), you are required to list each
148
+
third-party content explicitly with its version number in the documentation and your pull-request
149
+
comment. Please also check used third party material for license compatibility with the MPL-2.0.
242
150
E.g. software licensed under GPL, AGPL or, a similar strong copy-left license cannot be approved.
243
151
244
152
# Code Conventions
245
153
246
-
The SDS SDK JS Aspect Model loader is written in the Typescript Programming Language. Please have a look into
247
-
our [Code Conventions](CONVENTIONS.md).
248
-
249
-
# Release Process
250
-
251
-
The working group may decide that it reached a stable state for the contents of the repository.
252
-
To settle an agreement on this and provide downstream users with a stable version of the BAMM SDS SDK JS Aspect Model
253
-
loader,
254
-
a release process can be triggered.
255
-
256
-
For such a release the `working group` must approve the current state of the `main` branch as agreement.
257
-
A `maintainer` of the repository then forks the `main` branch into a new branch that follows the naming
258
-
convention `v{version_number}-RC`. The organization team of the OMP is then asked to `review & approve`
259
-
the `v{version_number}-RC` branch. If the organization agrees on the approval the OMP steering committee needs to be
260
-
notified. After that notification, a `maintainer` triggers the release feature from GitHub based on the commit on
261
-
which the `v{version_number}-RC` branch is based.
154
+
The ESMF SDK SDK JS Aspect Model loader is written in Typescript. Please have a look into our [Code
155
+
Conventions](CONVENTIONS.md).
262
156
263
157
## Versioning
264
158
265
-
We use Semantic Versioning to identify released versions of the SDS SDK JS Aspect Model loader. Semantic Versioning is
266
-
documented
267
-
[here](https://semver.org). It proposes to have a versioning number with the following elements:
159
+
We use Semantic Versioning to identify released versions of the ESMF SDK SDK JS Aspect Model loader. Semantic Versioning
160
+
is
161
+
documented [here](https://semver.org). It proposes to have a versioning number with the following
162
+
elements:
268
163
269
164
````
270
165
Given a version number MAJOR.MINOR.PATCH, increment the:
@@ -280,9 +175,10 @@ the Patch version must be incremented if backward-compatible bugfixes are introd
280
175
281
176
### Breaking Changes
282
177
283
-
For the definition of a breaking change, we follow the definition as in the
284
-
[Microsoft REST API Guidelines](https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#123-definition-of-a-breaking-change)
285
-
which are licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0). This definition states:
178
+
For the definition of a breaking change, we follow the definition as in the [Microsoft REST API
0 commit comments