History: Where to commit
Comparing version 352 with version 375
|
|||
| Lines: 1-21 | Lines: 1-24 | ||
| {DIV(class="lead well")}A very important decision is __where to commit__?: LTS? Stable? Dev? {DIV} | {DIV(class="lead well")}A very important decision is __where to commit__?: LTS? Stable? Dev? {DIV} | ||
| {BOX(title="General principle" align="left")} | {BOX(title="General principle" align="left")} | ||
| - | The general principle is that everything goes to master (trunk), and once approved, cherry-picked (backported) to still supported branches ( |
+ | The general principle is that everything goes to master (trunk), and once approved, cherry-picked (backported) to still supported branches (where more releases are planned). How far you can backport depends on the nature of the contribution.{BOX} |
| !! Where to commit | !! Where to commit | ||
| Commit status and order for each open branch: | Commit status and order for each open branch: | ||
| {FANCYTABLE(head="__Name__ |__Currently this is git branch__| __What is allowed in this branch__ | __Before commiting here, first commit to__ ")} | {FANCYTABLE(head="__Name__ |__Currently this is git branch__| __What is allowed in this branch__ | __Before commiting here, first commit to__ ")} | ||
| - | __Dev__|[https://gitlab.com/tikiwiki/tiki/commits/master|__master__(trunk)] (future 27x) | Functional [[ENH]ancements and new features, [[FIX]es and [[TRA]nslations %%% Most development (new features) happens here. __Next Stable__ | Dev__Current Stable__ |[https://gitlab.com/tikiwiki/tiki/-/tree/ ) __Previous Stable__ | None | Exists only until .1 release of Current Stable has been released. Then EoL or becomes the Previous Stable LTS | Current Stable__Previous Stable or Next Stable__Security fixes |
+ | __Dev__|[https://gitlab.com/tikiwiki/tiki/commits/master|__master__ (trunk)] (future 27x) | Functional [[ENH]ancements and new features, [[FIX]es and [[TRA]nslations %%% Most development (new features) happens here. New features need to be functional, but don't need to be complete. In theory, should be releasable at any time. This is the place for [[REF]actoring or cosmetic changes. %%% Also: {MOUSEOVER(label="Update language strings")}If you must change the English version (but are not changing the meaning and so the translations are still valid, please use ((mass spelling correction)). If you can't use that, just add to pending text corrections.{MOUSEOVER}. If you commit to master, and after you want to commit to a stable branch, please see how to ((git cherry-pick)). | This is the first place to propose a merge request (MR) __Next Stable__ | None | Exists only between the time Dev has been branched into the next stable, and the next stable .0 release has been released. Bug fixes and Translations only |Dev Dev__Current Stable__ | [https://gitlab.com/tikiwiki/tiki/-/tree/26.x|branches/26.x] | Bug fixes and minor safe enhancements | Dev, Next Stable (if ) __Previous Stable__ | None | Exists only until .1 release of Current Stable has been released. Then EoL or becomes the Previous Stable LTS | DevStable Current Stable__Previous Stable; LTS__|[https://gitlab.com/tikiwiki/tiki/-/tree/24.x|branches/24.x] | Minor safe enhancements, fixes and translations backported from Current Stable or Next Stable | Dev, Stable Stable or Next Stable__Security fixes only; LTS__ |[https://gitlab.com/tikiwiki/tiki/-/tree/21.x|branches/21.x] | Security fixes only | Dev, Current Stable or Next Stable, Previous Stable LTS |
| {FANCYTABLE} | {FANCYTABLE} | ||
| Legend: | Legend: | ||
| * STS: Standard Term Support | * STS: Standard Term Support | ||
| * LTS: Long Term Support | * LTS: Long Term Support | ||
| - | The table above shows which branch is appropriate to commit what type of code. How close we are to the release also has an impact (don't start a major refactoring just before a release). Please see: ((Freeze and Slush)) | + | The table above shows which branch is appropriate to commit what type of code. How close we are to the release also has an impact (ex.: don't start a major refactoring just before a release). Please see: ((Freeze and Slush)). Please be extra careful about backporting changes to the database schema. Please see: ((Database Schema Upgrade)) |
| Please also see: ((tw:Versions)) and ((Git Workflow)). | Please also see: ((tw:Versions)) and ((Git Workflow)). | ||
| Lines: 23-74 | Lines: 26-101 | ||
| Sometimes, shared feature branches can be created for major things that are not stable enough yet, and require multiple developers to collaborate over a long period. These branches will never become a released branch directly. | Sometimes, shared feature branches can be created for major things that are not stable enough yet, and require multiple developers to collaborate over a long period. These branches will never become a released branch directly. | ||
| - | For everything else, the author of the branch should create a [https://gitlab.com/help/user/project/merge_requests/index.md|Merge Request] from |
+ | For everything else, the author of the branch should create a [https://gitlab.com/help/user/project/merge_requests/index.md|Merge Request] (MR) from his/her personal branch when it's ready (or ((3 rules|even better)), a draft MR before it's ready). |
| !! The commit process (the human part) | !! The commit process (the human part) | ||
| - | # Create a merge # Use ** Add [https://gitlab.com/tikiwiki/tiki/-/labels|Tiki GitLab labels] such as needsCherryPicksTo26.x, needsCherryPicksTomaster or doNOTBackport as appropriate to the . *** ** Once the initial |
+ | !!! Standard process # Create a merge request (MR) from your personal fork on GitLab against [https://gitlab.com/tikiwiki/tiki|master] # Use GitLab labels to state your intentions on where your commit will . ** Add [https://gitlab.com/tikiwiki/tiki/-/labels|Tiki GitLab labels] such as needsCherryPicksTo26.x, needsCherryPicksTomaster or doNOTBackport as appropriate to the MR. It is each developer's responsibility to make sure these labels are created and removed for their own MR( ). *** You need developer access to create the labels (Guest or Reporter level is not enough). If you do not yet have developer access, or you are an external contributor, add the info in the MR description and someone will do it for you. Please see [https://gitlab.com/tikiwiki/tiki/-/project_members|list developers]. ** Once the initial MR is merged (and all pipelines are green), use ((Git cherry-pick)) to create additional MR(s) to cherry-pick into the appropriate branch(es). The __description should link to the initial MR__ so we know it was backported. |
| ** Remove the backport label from the initial MR __once the additional MR(s) have been created__ (do not wait for MRs to be merged in). | ** Remove the backport label from the initial MR __once the additional MR(s) have been created__ (do not wait for MRs to be merged in). | ||
| To see which merged MRs are still missing a cherry pick, use this GitLab query: https://gitlab.com/tikiwiki/tiki/-/merge_requests?scope=all&state=merged&label_name[]=needsCherryPicksTo%3A%3A* | To see which merged MRs are still missing a cherry pick, use this GitLab query: https://gitlab.com/tikiwiki/tiki/-/merge_requests?scope=all&state=merged&label_name[]=needsCherryPicksTo%3A%3A* | ||
| - | !! |
+ | !!! Alternate process In some cases, it's more productive for the developer to work against a branch (not master), and later to cherry pick to higher branches all the way to master. In this case, please use the label "needsCherryPicksTomaster https://gitlab.com/tikiwiki/tiki/-/merge_requests?scope=all&state=merged&label_name[]=needsCherryPicksTo%3A%3Amaster |
| - | # Don't hesitate to put MR back in ## It doesn't mean # ## When a reviewer comments or asks you a question, please try to answer quickly (so it's fresh in the reviewer's mind) |
+ | !! # Use MRs. Even core developers use them for their own commits (but frequently self merge them). This has a lot of benefits with overhead: ## You can make sure you didn't break the CI (Auto- and forget) ## If you did break something, whoever notices has a to discuss the change ## The commits on a MR can be grouped using arbitrary criterias (regardless of whether or not you intend to ultimately squash it) so it's least disruptive to your . Examples include: ### Daily work MR (very useful for seniors fixing a bunch of small independent without waiting for CI constantly) ### MR for collaborating with a specific person(s). Essentially micro-topic branches. Be careful not to force-push too much if you with other people on a MR. ### Draft MR containing your own small feature branch so you can get feedback or force the CI to run. # Don't hesitate to put a MR back in Draft (either as the author or the reviewer) ## It doesn't mean it's bad. Rather, it's a signal to reviewers not to re-review this until they are asked , or the MR is out of draft. # When you fixed __something in the code__ on a MR, don't just wait! Do something to inform the reviewer(s): (comment, resolve a thread, take the MR out of draft). MRs are rebased frequently, so the mere fact you code isn't enough information for reviewers to notice. ## When a reviewer comments or asks you a question, please try to answer quickly (so it's fresh in the reviewer's mind). |
| !! For MR reviewers | !! For MR reviewers | ||
| - | + | !!! What to review | |
| - | ### How is the code (does it improve the general quality of the code (not is it perfect...)? Is it understandable? ### What are the risks |
+ | * Does this make sense in Tiki? ** Does it duplicate functionality or code ** If a new library was added: ((How to pick a software library ) ** Will it break things for users? Code quality ** Is the code quality higher than average in Tiki? ** Is there copy-pasted code? * Does it like this was actually tested? ** As Victor wrote: "[https://gitlab.com/tikiwiki/tiki/-/merge_requests/1881#note_1147340658|code reviewers usually do code quality review and note specific areas to improve but we are not compilers. You have to test every place of you touch before committing]." !!! assessment: Keep context mind. ## For an initial MR ### How is the code (does it improve the general quality of the code (not is it perfect...)? Is it understandable? Does it seem to you the developer may be unaware of a way to do a similar thing in Tiki, etc. ### What are the risks? Aside from the obvious "This may lead to ", for a MR to master, important questions are **** Could this result in data corruption/ambiguity? **** Could this make the code much harder to refactor in the future? |
| ## For a MR on a branch | ## For a MR on a branch | ||
| - | ### The trade-offs are different. #### During a branch stabilization period, the risk is almost inexistant for most changes. |
+ | ### The trade-offs are different. On a branch, change is inherently more risky than on master. The MR has already been reviewed and approved once, so your question is more "What are the risks related to the difference between the two branches". #### During a branch stabilization period, the risk is almost inexistant for most changes. The further master has diverged from the branch, the more thought must be put into merging cherry-picks. |
| ### During stabilization periods, it is acceptable for more senior developers to cherry pick directly into the "Next Stable" branch, and remove labels as they do so | ### During stabilization periods, it is acceptable for more senior developers to cherry pick directly into the "Next Stable" branch, and remove labels as they do so | ||
| ### For the same reason, but for a longer period, one can group multiple unrelated cherry-picks in a single branch MR to backport them. | ### For the same reason, but for a longer period, one can group multiple unrelated cherry-picks in a single branch MR to backport them. | ||
| - | # Merging without pipelines after a rebase. When you are reviewing and merging multiple MR in a session, this can save a lot of time if you feel you know it won't break the pipeline. Just make sure it's not the last thing you do in the day, so you still have time to fix the pipeline. | ||
| - | See also: (( |
+ | !!! How to merge it # Rebase the # Check if the MR should be squashed, and if so, merge the text of the commit message so it represents the . # Merging without pipelines after a rebase. When you are reviewing and merging multiple MRs in a session, this can save a lot of time if you feel you know it won't break the pipeline. Just make sure it's not the last thing you do in the day, so you still have time to fix pipeline. See also: ((Tools for Merge Request reviewers)) |
| !! When is this supposed to be released? | !! When is this supposed to be released? | ||
| - | See |
+ | See ((Version lifecycle)) |
| !! Definition of "security-only" phase | !! Definition of "security-only" phase | ||
| Lines: 82-87 | Lines: 109-113 | ||
| !! Other notes | !! Other notes | ||
| - | * * |
+ | * If you're working on ((Cypht)) Webmail, please see https://github.com/cypht-org/cypht/wiki/Lifecycle and ((How to upgrade Cypht within Tiki via Composer)) |
| * If you must change the English version (but are not changing the meaning and so the translations are still valid, please use ((Mass spelling correction)). If you can't use that, just add to ((Pending text corrections)) | * If you must change the English version (but are not changing the meaning and so the translations are still valid, please use ((Mass spelling correction)). If you can't use that, just add to ((Pending text corrections)) | ||
| * If we are close to a release, and you have a change with a risk of regression, try to consult the ((tw:Release Roles|release manager)). | * If we are close to a release, and you have a change with a risk of regression, try to consult the ((tw:Release Roles|release manager)). | ||
History
;){kind=link}
;){kind=link}
- Page description, when activated, is always used in browser title display mode
- Anonymous user can't switch perspectives - new permission needed.
- Better colors for the text color toolbar tool in Tiki
- line 1504 of wikiplugin_img.php appends px regardless of what width is
- Admin bar module causes fatal error
;){kind=link}
;){kind=link}