@@ -81,10 +81,10 @@ The high-level content required or optional in a merge request and the related c
### Merge request
| Id | Field | Provision | Description |
| ---| ----- | ------- | -----------:|
| ---| ----- | :------ | :-----------|
|M01 | Unique URL | Mandatory | E.g. <forge>/<my-group>/<my-project>/merge_requests/<ID> |
|M02 | Diff : Changes in the software | Mandatory | |
|M03 | Motivation, rationale or purpose of the changes | |
|M03 | Motivation, rationale or purpose of the changes | ||
|M04 | Description of the changes | Mandatory | |
|M05 | Green light from CI Validation | Mandatory | |
|M06 | Software URL | Mandatory | E.g. <forge>/<my-group>/<my-repo>/0.0.x |
@@ -93,22 +93,14 @@ The high-level content required or optional in a merge request and the related c
### Contribution to the Portal
Id Field Provision Description
C01 Link to MR so that software can be reviewed Mandatory
C0x Reason for Change Mandatory
If the contribution does not propose any change beyond those in the Merge Request, this field can refer to the Reason for Change of the Merge Request.
C0x Description of the Change Mandatory
If the contribution does not propose any change beyond those in the Merge Request, this field can refer to the Description of Change of the Merge Request.
C02 Number of the latest commit in the merge request Mandatory
C03 Changes in the text pointing to the software
Mandatory
E.g.:Data model A is available at <forge>/ <my-group>/ <my-project>/ <my-title>/ A.yaml”
C04 Changes in other elements of the deliverable required to maintain consistency with the changes proposed by the MR Optional
(see note) e.g.
- Changes to a normative textual statement that explicitly calls out an attribute being removed by the Merge Request.
- Changes to an example that illustrates the use of an attribute whose syntax is being changed by the Merge Request.
NOTE: If the changes made to the “software” do not impact other elements, this shall be explicitly stated.
| C01 | Link to MR so that software can be reviewed | Mandatory | |
| C02 | Reason for Change | Mandatory | If the contribution does not propose any change beyond those in the Merge Request, this field can refer to the Reason for Change of the Merge Request. |
| C03 | Description of the Change | Mandatory | If the contribution does not propose any change beyond those in the Merge Request, this field can refer to the Description of Change of the Merge Request. |
| C04 | Number of the latest commit in the merge request | Mandatory | |
| C05 | Changes in the text pointing to the software | Mandatory | E.g.:Data model A is available at <forge>/ <my-group>/ <my-project>/ <my-title>/ A.yaml” |
| C06 | Changes in other elements of the deliverable required to maintain consistency with the changes proposed by the MR | Optional (see note) | E.g. <br/>- Changes to a normative textual statement that explicitly calls out an attribute being removed by the Merge Request.<br/>- Changes to an example that illustrates the use of an attribute whose syntax is being changed by the Merge Request.<br/>NOTE: If the changes made to the “software” do not impact other elements, this shall be explicitly stated. |
Editor’s note: a mapping to the CR form could be done with guidance.
@@ -117,19 +109,19 @@ Editor’s note: a mapping to the CR form could be done with guidance.
### Rapporteur Merge and tag changes
• Merge approved Merge Requests
• Tag with new draft number e.g. 0.0.2
-Merge approved Merge Requests
-Tag with new draft number e.g. 0.0.2
### Create new draft
• Apply text changes
• Search and replace any occurrence of <forge>/my-group/my-project/<whatever>/ to <forge>/my-group/my-project/v0.0.2/
-Apply text changes
-Search and replace any occurrence of <forge>/my-group/my-project/<whatever>/ to <forge>/my-group/my-project/v0.0.2/
# Branching and tagging strategy
• Published versions should be tagged with the publication version, e.g. 1.1.1
o Published tags should allow for editorials to be fixed and to issue a new branch, e.g. 1.1.1-1
• Publication branch i.e. the branch containing the publishable /published versions of the files.
-Published versions should be tagged with the publication version, e.g. 1.1.1
-Published tags should allow for editorials to be fixed and to issue a new branch, e.g. 1.1.1-1
-Publication branch i.e. the branch containing the publishable /published versions of the files.
## Usage of TAGs
@@ -141,8 +133,10 @@ By their nature, they are well suited to identify revisions of the software in t
### Guidelines
Drafting tags and publication tags should be protected, i.e. they are applicable by privileged users, which may be the Rapporteur of the related document, “power users” nominated by the TB or members of ETSI Secretariat.
o NOTE 1: The definition of tag name templates is left for future study
o NOTE 2: TAGs, once applied shall not be removed and re-applied (though technically possible).
> NOTE 1: The definition of tag name templates is left for future study
> NOTE 2: TAGs, once applied shall not be removed and re-applied (though technically possible).
