-
Notifications
You must be signed in to change notification settings - Fork 141
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
DOC: try fix not rendered branches table
- Loading branch information
Thomas Günther
committed
Jun 20, 2023
1 parent
b6eef3e
commit 734e627
Showing
2 changed files
with
12 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -97,17 +97,17 @@ into the dev branch and delete the branch. | |
Branches | ||
-------- | ||
|
||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
| Branch name | Description | Purpose | CI (Jenkins) Current behavior | CI (Jenkins) Wishlist | Rules | | ||
+==============+============================+========================================================================================================================================================================================================================================+=============================================================================================================================================================================================+===============================================================================================================================+========================================================================================================================+ | ||
| dev | Main development branch | This is where new versions are developed and pull requests are merged to. | Build and test, on success generate http://dev.pygimli.org and merge to master | Test pull requests, build nightly conda packages for test channel | Run pg.test() and make doc before pushing. Tag related issues in commit message. | | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
| release | Latest release | This is where releases are "staged". This usually means creating a git tag and manually merging dev into release. Hot fixes and website typos can be directly committed here. | Start in empty workspace, build, test and create documentation after each push. On success, merge into master and update http://www.pygimli.org. | Test "backward compatibility" (e.g., run example scripts from last release with this version). Test on Mac and Windows, too. | Make sure the tag is annotated and the version string is following the principles described below. | | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
| master | Latest tested dev | Make sure that if people checkout the repository, they always have a working version. | (represented by http://dev.pygimli.org) | Build pgcore (if necessary) and pygimli conda packages for release. | Never push anything to master! | | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
| * | Feature branches | Larger endeavors and major restructuring should happen in dedicated feature branches (or forks), which are eventually merged to dev. This can also be useful if you want to give write access to others to jointly work on a feature. | Automatic testing can be requested ([email protected]). | | Start feature branch from dev. Inform other developers about your develpment (to avoid conflicts and redundant work). | | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
| Branch name | Description | Purpose | CI (Jenkins) Current behavior | CI (Jenkins) Wishlist | Rules | | ||
+==============+============================+========================================================================================================================================================================================================================================+==================================================================================================================================================+==============================================================================================================================+========================================================================================================================+ | ||
| dev | Main development branch | This is where new versions are developed and pull requests are merged to. | Build and test, on success generate http://dev.pygimli.org and merge to master | Test pull requests, build nightly conda packages for test channel | Run pg.test() and make doc before pushing. Tag related issues in commit message. | | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
| release | Latest release | This is where releases are "staged". This usually means creating a git tag and manually merging dev into release. Hot fixes and website typos can be directly committed here. | Start in empty workspace, build, test and create documentation after each push. On success, merge into master and update http://www.pygimli.org. | Test "backward compatibility" (e.g., run example scripts from last release with this version). Test on Mac and Windows, too. | Make sure the tag is annotated and the version string is following the principles described below. | | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
| master | Latest tested dev | Make sure that if people checkout the repository, they always have a working version. | (represented by http://dev.pygimli.org) | Build pgcore (if necessary) and pygimli conda packages for release. | Never push anything to master! | | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
| * | Feature branches | Larger endeavors and major restructuring should happen in dedicated feature branches (or forks), which are eventually merged to dev. This can also be useful if you want to give write access to others to jointly work on a feature. | Automatic testing can be requested ([email protected]). | | Start feature branch from dev. Inform other developers about your develpment (to avoid conflicts and redundant work). | | ||
+--------------+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+ | ||
|
||
Commit messages | ||
--------------- | ||
|