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
Thank you for considering contributing to our Python package! We appreciate your time and effort in helping us improve our project. Please take a moment to review the following guidelines to ensure a smooth and efficient contribution process.
@@ -16,9 +15,9 @@ To set up the development environment for this Python package, follow these step
16
15
1. Clone the repository to your local machine using the command:
17
16
18
17
```
19
-
git clone https://github.com/basf/mamba-tabular
18
+
git clone https://github.com/OpenTabular/DeepTab
20
19
21
-
cd mamba-tabular
20
+
cd DeepTab
22
21
```
23
22
24
23
2. Install tools required for setting up development environment:
@@ -45,7 +44,7 @@ just install
45
44
In case you are not able to install `just`, you can follow the below steps to set up the development environment:
**Note:** You can also set up a virtual environment to isolate your development environment.
62
61
63
-
64
62
### How to Contribute
65
63
66
64
1. Create a new branch from the `develop` branch for your contributions. Please use descriptive and concise branch names.
67
65
2. Make your desired changes or additions to the codebase.
68
66
3. Ensure that your code adheres to [PEP8](https://peps.python.org/pep-0008/) coding style guidelines.
69
67
4. Write appropriate tests for your changes, ensuring that they pass.
70
-
-`make test`
68
+
-`make test`
71
69
5. Update the documentation and examples, if necessary.
72
70
6. Build the html documentation and verify if it works as expected. We have used Sphinx for documentation, you could build the documents as follows:
73
-
-`cd src/docs`
74
-
-`make clean`
75
-
-`make html`
71
+
-`cd src/docs`
72
+
-`make clean`
73
+
-`make html`
76
74
7. Verify the html documents created under `docs/_build/html` directory. `index.html` file is the main file which contains link to all other files and doctree.
77
75
78
-
8. Commit your changes with a clear and concise commit message.
76
+
8. Commit your changes following the Conventional Commits specification (see below).
79
77
9. Submit a pull request from your branch to the development branch of the original repository.
80
78
10. Wait for the maintainers to review your pull request. Address any feedback or comments if required.
81
79
11. Once approved, your changes will be merged into the main codebase.
82
80
81
+
### Release Workflow
82
+
83
+
This project uses automated semantic versioning and releases. Here's how releases work:
84
+
85
+
#### Automated Release Process
86
+
87
+
```
88
+
1. Make Changes → 2. Conventional Commit → 3. Merge to Master → 4. Automated Release
89
+
```
90
+
91
+
**Step-by-Step:**
92
+
93
+
1.**Development Phase**
94
+
95
+
- Create feature branch from `develop`
96
+
- Make your changes
97
+
- Commit using conventional commits (e.g., `feat:`, `fix:`)
98
+
99
+
2.**Merge to Develop**
100
+
101
+
- Create PR to `develop` branch
102
+
- After review, merge to `develop`
103
+
- ReadTheDocs dev documentation updates automatically
# Merge to master → Version 1.6.1 → 1.7.0 → PyPI release
151
+
```
152
+
153
+
**Scenario 4: Breaking Change (Major Release)**
154
+
155
+
```bash
156
+
git commit -m "feat!: remove Python 3.9 support
157
+
158
+
BREAKING CHANGE: Python 3.10 is now the minimum required version"
159
+
# Merge to master → Version 1.6.1 → 2.0.0 → PyPI release
160
+
```
161
+
162
+
#### Important Notes
163
+
164
+
-**Only master branch** triggers releases
165
+
-**Semantic-release is fully automated** - no manual version bumping needed
166
+
-**Never manually edit version numbers** in `pyproject.toml` or `deeptab/__version__.py` - they are automatically updated by semantic-release
167
+
-**PyPI token** is configured in GitHub repository secrets
168
+
-**Review commits carefully** before merging to master (they determine the version!)
169
+
170
+
#### Working with Updated Versions
171
+
172
+
**Q: What happens if I create a branch from `develop` after a release?**
173
+
174
+
After a release is merged to `master`, the version files are updated automatically. To get the latest version:
175
+
176
+
1.**Sync develop with master** (maintainers do this):
177
+
178
+
```bash
179
+
git checkout develop
180
+
git merge master
181
+
git push origin develop
182
+
```
183
+
184
+
2.**Update your local develop branch** (before creating new branches):
185
+
186
+
```bash
187
+
git checkout develop
188
+
git pull origin develop
189
+
```
190
+
191
+
3.**Create your feature branch from updated develop**:
192
+
```bash
193
+
git checkout -b feature/my-new-feature
194
+
```
195
+
196
+
This ensures your branch has the correct version number as a starting point. Don't worry if the version seems "old" in your branch - semantic-release will calculate the correct new version based on commits when merging to master.
197
+
83
198
### Submitting Contributions
84
199
85
200
When submitting your contributions, please ensure the following:
@@ -93,7 +208,7 @@ When submitting your contributions, please ensure the following:
93
208
94
209
### Issue Tracker
95
210
96
-
If you encounter any bugs, have feature requests, or need assistance, please visit our [Issue Tracker](https://github.com/basf/mamba-tabular/issues). Make sure to search for existing issues before creating a new one.
211
+
If you encounter any bugs, have feature requests, or need assistance, please visit our [Issue Tracker](https://github.com/OpenTabular/DeepTab/issues). Make sure to search for existing issues before creating a new one.
0 commit comments