vizor_gui_tools 1.7.9 → 1.8.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +136 -136
- package/dist/vizor_gui_tools.min.js +1 -1
- package/package.json +41 -41
package/README.md
CHANGED
|
@@ -1,136 +1,136 @@
|
|
|
1
|
-
# vizor_gui_tools
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
A series of GUI Tools to be used in the VIZOR ENGINE PLATFORM
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
- windows
|
|
8
|
-
- menus
|
|
9
|
-
- toolboxes
|
|
10
|
-
- controls
|
|
11
|
-
- forms
|
|
12
|
-
|
|
13
|
-
# VIZOR Collaborator instructions
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
FIRST TIME :
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
1. Clone the project:
|
|
20
|
-
|
|
21
|
-
git clone https://github.com/your-username/your-repository.git
|
|
22
|
-
|
|
23
|
-
2. Modify:
|
|
24
|
-
|
|
25
|
-
Make your changes in the codebase.
|
|
26
|
-
|
|
27
|
-
3. Create a local branch:
|
|
28
|
-
|
|
29
|
-
- NOTA : Como nombre del branch se puede usar la versión,
|
|
30
|
-
ejemplo : release-vX.Y.Z
|
|
31
|
-
|
|
32
|
-
Colocar en CHANGELOG.md el detalle de los cambios realizados.
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
git checkout -b feature-branch-name
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
4. Add and commit changes:
|
|
40
|
-
|
|
41
|
-
git add .
|
|
42
|
-
git commit -m "Description of the changes"
|
|
43
|
-
|
|
44
|
-
5. Push the branch:
|
|
45
|
-
|
|
46
|
-
git push origin feature-branch-name
|
|
47
|
-
|
|
48
|
-
6. Create a pull request on GitHub.
|
|
49
|
-
|
|
50
|
-
7. Ask the owner to accept and merge
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
NEXT STEPS (Continous Development)
|
|
55
|
-
|
|
56
|
-
1. pull to have the lastest changes
|
|
57
|
-
|
|
58
|
-
git checkout main
|
|
59
|
-
git pull origin main
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
2. create a new branch (use a name that clearly comunicate the featur you ar working on)
|
|
63
|
-
|
|
64
|
-
git checkout -b new-feature-branch
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
3. Make your changes in the codebase.
|
|
68
|
-
|
|
69
|
-
4. push the new changes
|
|
70
|
-
|
|
71
|
-
git add .
|
|
72
|
-
git commit -m "Description of changes"
|
|
73
|
-
git push origin new-feature-branch
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
# Managing Versioning
|
|
79
|
-
|
|
80
|
-
Determine the version update type:
|
|
81
|
-
Decide whether the changes constitute a major, minor, or patch update based on the Semantic
|
|
82
|
-
|
|
83
|
-
Versioning guidelines:
|
|
84
|
-
|
|
85
|
-
Major: Incompatible API changes.
|
|
86
|
-
Minor: Backward-compatible functionality.
|
|
87
|
-
Patch: Backward-compatible bug fixes.
|
|
88
|
-
|
|
89
|
-
Update the version number:
|
|
90
|
-
Update the version number in the relevant files (e.g., package.json for Node.js projects) based on the determined version update type.
|
|
91
|
-
|
|
92
|
-
1. Create a release branch:
|
|
93
|
-
|
|
94
|
-
git checkout main
|
|
95
|
-
git pull origin main
|
|
96
|
-
git checkout -b release-vX.Y.Z
|
|
97
|
-
Update the changelog:
|
|
98
|
-
Document the changes in a CHANGELOG.md file, outlining the new features, bug fixes, and other relevant information for the release.
|
|
99
|
-
|
|
100
|
-
2. Commit the version update and changelog:
|
|
101
|
-
|
|
102
|
-
git add .
|
|
103
|
-
git commit -m "Bump version to vX.Y.Z and update changelog"
|
|
104
|
-
|
|
105
|
-
3. Push the release branch:
|
|
106
|
-
|
|
107
|
-
git push origin release-vX.Y.Z
|
|
108
|
-
|
|
109
|
-
4. Create a pull request for the release branch:
|
|
110
|
-
|
|
111
|
-
5. Create a pull request to merge the release branch into the main branch.
|
|
112
|
-
|
|
113
|
-
6. Merge the pull request:
|
|
114
|
-
|
|
115
|
-
Once reviewed and approved, merge the pull request.
|
|
116
|
-
|
|
117
|
-
7. Tag the release:
|
|
118
|
-
|
|
119
|
-
8. After merging, create a tag for the new release:
|
|
120
|
-
|
|
121
|
-
git checkout main
|
|
122
|
-
git pull origin main
|
|
123
|
-
git tag -a vX.Y.Z -m "Release version vX.Y.Z"
|
|
124
|
-
git push origin vX.Y.Z
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
9. Create a release on GitHub:
|
|
128
|
-
|
|
129
|
-
Go to the GitHub repository, navigate to the "Releases" section, and create a new release using the created tag. Provide the release notes based on the changelog.
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
By following these steps, you'll maintain a well-organized versioning system, ensuring that the codebase remains structured and that changes are properly documented and released.
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
1
|
+
# vizor_gui_tools
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
A series of GUI Tools to be used in the VIZOR ENGINE PLATFORM
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
- windows
|
|
8
|
+
- menus
|
|
9
|
+
- toolboxes
|
|
10
|
+
- controls
|
|
11
|
+
- forms
|
|
12
|
+
|
|
13
|
+
# VIZOR Collaborator instructions
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
FIRST TIME :
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
1. Clone the project:
|
|
20
|
+
|
|
21
|
+
git clone https://github.com/your-username/your-repository.git
|
|
22
|
+
|
|
23
|
+
2. Modify:
|
|
24
|
+
|
|
25
|
+
Make your changes in the codebase.
|
|
26
|
+
|
|
27
|
+
3. Create a local branch:
|
|
28
|
+
|
|
29
|
+
- NOTA : Como nombre del branch se puede usar la versión,
|
|
30
|
+
ejemplo : release-vX.Y.Z
|
|
31
|
+
|
|
32
|
+
Colocar en CHANGELOG.md el detalle de los cambios realizados.
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
git checkout -b feature-branch-name
|
|
37
|
+
|
|
38
|
+
|
|
39
|
+
4. Add and commit changes:
|
|
40
|
+
|
|
41
|
+
git add .
|
|
42
|
+
git commit -m "Description of the changes"
|
|
43
|
+
|
|
44
|
+
5. Push the branch:
|
|
45
|
+
|
|
46
|
+
git push origin feature-branch-name
|
|
47
|
+
|
|
48
|
+
6. Create a pull request on GitHub.
|
|
49
|
+
|
|
50
|
+
7. Ask the owner to accept and merge
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
NEXT STEPS (Continous Development)
|
|
55
|
+
|
|
56
|
+
1. pull to have the lastest changes
|
|
57
|
+
|
|
58
|
+
git checkout main
|
|
59
|
+
git pull origin main
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
2. create a new branch (use a name that clearly comunicate the featur you ar working on)
|
|
63
|
+
|
|
64
|
+
git checkout -b new-feature-branch
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
3. Make your changes in the codebase.
|
|
68
|
+
|
|
69
|
+
4. push the new changes
|
|
70
|
+
|
|
71
|
+
git add .
|
|
72
|
+
git commit -m "Description of changes"
|
|
73
|
+
git push origin new-feature-branch
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
# Managing Versioning
|
|
79
|
+
|
|
80
|
+
Determine the version update type:
|
|
81
|
+
Decide whether the changes constitute a major, minor, or patch update based on the Semantic
|
|
82
|
+
|
|
83
|
+
Versioning guidelines:
|
|
84
|
+
|
|
85
|
+
Major: Incompatible API changes.
|
|
86
|
+
Minor: Backward-compatible functionality.
|
|
87
|
+
Patch: Backward-compatible bug fixes.
|
|
88
|
+
|
|
89
|
+
Update the version number:
|
|
90
|
+
Update the version number in the relevant files (e.g., package.json for Node.js projects) based on the determined version update type.
|
|
91
|
+
|
|
92
|
+
1. Create a release branch:
|
|
93
|
+
|
|
94
|
+
git checkout main
|
|
95
|
+
git pull origin main
|
|
96
|
+
git checkout -b release-vX.Y.Z
|
|
97
|
+
Update the changelog:
|
|
98
|
+
Document the changes in a CHANGELOG.md file, outlining the new features, bug fixes, and other relevant information for the release.
|
|
99
|
+
|
|
100
|
+
2. Commit the version update and changelog:
|
|
101
|
+
|
|
102
|
+
git add .
|
|
103
|
+
git commit -m "Bump version to vX.Y.Z and update changelog"
|
|
104
|
+
|
|
105
|
+
3. Push the release branch:
|
|
106
|
+
|
|
107
|
+
git push origin release-vX.Y.Z
|
|
108
|
+
|
|
109
|
+
4. Create a pull request for the release branch:
|
|
110
|
+
|
|
111
|
+
5. Create a pull request to merge the release branch into the main branch.
|
|
112
|
+
|
|
113
|
+
6. Merge the pull request:
|
|
114
|
+
|
|
115
|
+
Once reviewed and approved, merge the pull request.
|
|
116
|
+
|
|
117
|
+
7. Tag the release:
|
|
118
|
+
|
|
119
|
+
8. After merging, create a tag for the new release:
|
|
120
|
+
|
|
121
|
+
git checkout main
|
|
122
|
+
git pull origin main
|
|
123
|
+
git tag -a vX.Y.Z -m "Release version vX.Y.Z"
|
|
124
|
+
git push origin vX.Y.Z
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
9. Create a release on GitHub:
|
|
128
|
+
|
|
129
|
+
Go to the GitHub repository, navigate to the "Releases" section, and create a new release using the created tag. Provide the release notes based on the changelog.
|
|
130
|
+
|
|
131
|
+
|
|
132
|
+
By following these steps, you'll maintain a well-organized versioning system, ensuring that the codebase remains structured and that changes are properly documented and released.
|
|
133
|
+
|
|
134
|
+
|
|
135
|
+
|
|
136
|
+
|