History: Where to commit
Comparing version 273 with version 397
Go to current version
|
|
||
| Lines: 1-143 | Lines: 1-158 | ||
| - | {DIV(class="lead well")}Once you have read up on how to ((commit code)), a very important decision is __where to commit__? Stable-LTS, Stable, Dev (trunk on SVN / master on Git), or experimental? You may want to checkout the ((tw:Versions)) page. | ||
| - | See also: ((Freeze and Slush)) and ((Git and SVN Combined Workflow)){DIV} | ||
| - | Quick overview intended {BOX(title=" ** For example if you want to make a fix to 15.x LTS, please commit the fix to 20.x first then backport to 19.x the table below. ** During this period, changes to trunk/master increase the risks of ((merge conflicts)). To minimize this risk, non be postponed ~tc~* below * ** , 19.2, 18.4 LTS, 15.8 LTS and 12.15 LTS be the next versions released.'' |
+ | {DIV(class="lead well")}A very important decision is __where to commit__?: LTS? Stable? Dev? {DIV} {BOX(title="General principle" align="left") The general principle is that everything goes to master (trunk), and once approved and __if there is a specific reason__, cherry-picked (backported) to still supported branches (where more releases are planned). How far you can backport depends on the nature of the contribution. You need to follow the ((Backport Policy)){BOX} |
| + | !! Where to commit (backport chain) | ||
| Commit status and order for each open branch: | Commit status and order for each open branch: | ||
| - | {FANCYTABLE(head=" |
+ | {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 31x) ~|~ Functional [[ENH]ancements and new features %%% [[FIX]es and [[TRA]nslations %%% Most development (new features) happens here %%% This is the place for [[REF]actoring or cosmetic changes. %%% Features must be functional but don’t have to be fully complete. %%% In theory, should be releasable at any time. 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 (branched, unreleased) __ ~|~ [https://gitlab.com/tikiwiki/tiki/-/tree/30.x|branches/30.x] ~|~ 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 (released)__ ~|~ [https://gitlab.com/tikiwiki/tiki/-/tree/29.x|branches/29.x] ~|~ Bug fixes and minor safe enhancements ~|~ Dev, Next Stable ( any) __Previous Stable__ ~|~ None ~|~ Exists only until .1 release of Current Stable has been released. Then EoL or becomes the Previous Stable LTS ~|~ Stable , Current Stable__Previous Stable LTS__ ~|~ [https://gitlab.com/tikiwiki/tiki/-/tree/27.x|branches/27.x] ~|~ Minor safe enhancements, fixes and translations backported from Current Stable or Next Stable ~|~ Dev,Stable Current Stable or Next Stable__Security fixes only LTS (previous LTS)__ ~|~ [https://gitlab.com/tikiwiki/tiki/-/tree/24.x|branches/24.x] ~|~ Security fixes only ~|~ Dev, Current Stable or Next Stable, Previous Stable LTS |
| {FANCYTABLE} | {FANCYTABLE} | ||
| - | + | Legend: * STS: Standard Term * LTS: Long Term Support | |
| - | ''Root |
+ | 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)). |
| - | Dev|[https://svn.code.sf.net/p/tikiwiki/code/trunk/|trunk]/[https://gitlab.com/tikiwiki/tiki/commits/master|master](will become 21.x branch in future) |Most development (new features) happens here. New features, need to __Stable__|[https://svn.code.sf.net/p/tikiwiki/code/branches/20.x/|branches/20.x] |__Fixes only__ - Auto-merged to trunk/ . __Previous Stable__|[https://svn.code.sf.net/p/tikiwiki/code/branches/19.x/|branches/19.x] |__Fixes only__ until after 20.0 backported x 20.x __Stable LTS__|[https://svn.code.sf.net/p/tikiwiki/code/branches/18.x/|branches/18.x] |__Fixes only__ until after 20.0 x from 19.x__Previous Stable LTS__|[https://svn.code.sf.net/p/tikiwiki/code/branches/15.x/|branches/15.x] |__Security and bug fixes. __ Backport 18.x. Previous Stable LTS|[https://svn.code.sf.net/p/tikiwiki/code/branches/12.x/|branches/12.x]|__Only security fixes and translations. __ from 15.x. ((Experimental branches))|[https://svn.code.sf.net/p/tikiwiki/code/branches/experimental/|many]|All developments for things that are not stable enough yet or just intended as proof of concept before the real work starts. These branches will never become a released branch directly, the author of the experimental branch must move the functionality in the Dev branch when it's ready.|| |
+ | Please be extra careful about backporting changes to the database schema. Please see: ((Database Schema Upgrade)) |
| - | * The "security-only" of the LTS period is intended for security fixes ** We will review security vulnerabilities reported to the ** Publish a fix or a way to deactivate feature. *** If the included code doesn't have a for that version * What if a security vulnerability requires major code changes for LTS? ** We'll disable the feature via , or upgrade. * The documentation at doc.tiki.org is kept up to date for more recent versions, so expect to see there some documentation about features not available in your Tiki |
+ | __Please also see:__ ((Backport guidelines)), ((tw:Versions)), and ((Git Workflow)). |
| - | * Commits to LTS must have been developed and tested previously on higher branches (at least trunk/master) unless they do not apply there (for example * The community will handle merges from stable to dev, with help from a merging script during ((Semi-automatic merging period ) * On stable branches, __try to avoid any changes to the database as this complicates )) * If you must change the English version (but )) * If we are close release manager]. * There are some things that are black and white and there are many shades of gray. In case of doubt, ask on the ( Dev Mailing List)) * https://trunkbaseddevelopment |
+ | 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. |
| - | __There are no more planned releases |
+ | 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) |
| - | + | !!! 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 needsCherryPicksTo27.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 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). | |
| - | * lphuberdeau marclaporte * * nyloth * pkdille |
+ | 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* |
| - | r13615 : M |
+ | !!! 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 "CherryPickTo:master https://gitlab.com/tikiwiki/tiki/-/merge_requests?scope=all&state=merged&label_name[]=CherryPickTo%3A%3Amaster |
| - | + | !!! Exceptions "The general principle is that everything goes to master (trunk), and once approved and __if there is a specific reason__, cherry-picked (backported) to still supported branches * Content in vendor_bundled/composer.lock and the equivalent for the ((The Tiki 27 plus Build System|the JS build system)) is not backported but regenerated for each branch (which may have different ) * If an issue only affects an older version (ex.: 27.x) but not later versions: Make a MR against that branch while indicating in the commit message why this is an exception (Ex.: "This bug affects 24.x and older branches, but not 27.x+". Even better if you can indicate why. Ex.: "27.x uses library X in a different way so it's not affected by the ") * Some backports (especially to older branches) can't be identical code. The code needs to be adapted. For example, to support an older PHP versions. Please indicate this in the commit message so reviewers know it's intentional. | |
| - | + | !! Collaborating | |
| - | linesChanged : /templates/tiki /tiki /tiki-parsemode_setup |
+ | # Use MRs. Even core developers use them for their own commits (but frequently self merge them). This has a lot of benefits with little overhead: ## You can make sure you didn't break the CI (Auto-merge and forget ## If you did break something, whoever notices has a place to discuss 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 flow. include: ### Daily work MR (very useful for seniors fixing a bunch of small independent things without waiting CI constantly) ### MR for collaborating with a specific person(s). Essentially micro-topic branches. Be careful not to force-push too much if you collaborate with other on a MR. ### Draft MR containing your own small feature branch so you can get feedback, or the CI to run. # Don't hesitate to put a MR back in Draft (either 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 to, 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 pushed 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). |
| - | [FIX] Markup not parsed when switching from normal (wiki) to wysiwyg (html) editors (itemId=1831) | ||
| - | {CODE} | ||
| - | * This commit changes a desired behavior and may break the release. Changes should be discussed with original authors and any decided changes are to be made in trunk/master * All changes in branches/2.0 need to be safe and fully tested with all related features, including translation and staging. |
+ | !! For MR reviewers |
| - | r13612 linesChanged : M /branches/2. /lib/wiki-plugins/wikiplugin_tracker.php M /branches/2. /templates/messu-compose.tpl M /branches/2. /templates/tiki-admin_forums.tpl M /branches/2. /templates/tiki-admin_menu_options.tpl M /branches/2. /templates/tiki-admin_notifications.tpl M /branches/2. /templates/tiki-adminusers.tpl M /branches/2. /templates/tiki-batch_upload.tpl M /branches/2. /templates/tiki-batch_upload_files.tpl M /branches/2. /templates/tiki-list_comments.tpl M /branches/2. /templates/tiki-received_pages.tpl M /branches/2. /templates/tiki-view_tracker.tpl M /branches/2. /templates/tiki-view_tracker_item.tpl M /branches/2. /templates/tracker_item_field_input.tpl |
+ | !!! What to review |
| - | var only gets set for people with some reason) {CODE} |
+ | * 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 code you touch before committing]." |
| - | * |
+ | !!! Risk assessment: Keep context in mind. |
| - | /templates/tiki |
+ | ## 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 standardized way to do a similar thing in Tiki, etc ### What are the risks? Aside from the obvious "This may lead to bugs", for a MR to master, important are **** Could this result in data corruption ambiguity? **** Could this make the code much harder to refactor the future? ## For MR on a branch ### 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 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 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 ### For the same reason, but for a longer period, one can group multiple unrelated cherry-picks in a single branch MR to backport them. |
| - | + | !!! 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 the pipeline. | |
| - | + | !!! How do you handle comments on MR or responses to review feedback? When reviewing code on GitLab, it's essential to understand the different options available to you when giving your opinion on a Pull Request or reviewer feedback. The four main choices are Comment * Approve * Request Changes Pending Comment. Each has a specific role and in terms of your feedback. ** __Comment__ : Make comments without requesting changes The Comment option is used when you have feedback to make, but it does not mandatory correction before merging the code. ** __Approve__: Approve Code for Merge The Approve option is used when you are satisfied with the submitted code and feel it is to be merged with the main branch. ** __Request Changes__: Requesting modifications before merging When you find problems in the code that need to be resolved before it is merged, use Request Changes. This option is essential when the code contains that compromise quality, security or functionality. ** __Pending Comment__: The Pending Comment option is used when you've started writing comments, but haven't yet decided whether to publish them. Pending comments visible only to you until they been submitted. __This option is useful when__ : You want to review all your comments before submitting them. *You prefer to write several comments before finalizing your review. __Note__: When you choose the pending comment option, pending comments are visible only to you until they been submitted. And this delays reviewers from approaching your __ request. __how to make your comments visible in pending comment mode ?__To make your comments visible to others, click on the __Submit button after writing your comments.__ This will publish all pending comments at once. __Reply to Reviewers' Comments:__For who receive feedback from reviewers, it's important to know how to respond effectively: ** Take every comment into account: Review every left by reviewers, whether blocking or not. Even suggestions can help improve code quality. ** Mark comments as resolved: When you've made the requested changes, reply to the comment to indicate what you've done mark it as resolved. This allows reviewers to see that their feedback has been taken into account. ** Ask for clarification : If a comment is unclear, don't hesitate ask questions to better understand what's expected. It also shows your commitment to improving the code. **Explain your choices : If you don't follow a suggestion provide a clear explanation.__ Open discussions are useful to ensure that everyone is aligned with the decisions made. __How to choose the right option?__The choice between Comment, Approve, Request Changes, and Pending Comment depends essentially on the quality of the code and the impact of the problems you detect. | |
| - | {CODE(wrap=>1)} | ||
| - | r13600 | pkdille | 2008-07-11 16:44:40 -0400 (Fri, 11 Jul 2008) | 1 line | ||
| - | Changed paths: | ||
| - | M /branches/2.0/templates/tiki-objectpermissions.tpl | ||
| - | * |
+ | See also: ((Tools for Merge Request reviewers)) !! When is this supposed to be ? See (( lifecycle)) !! Definition of " -only" phase * The "security-only" of the LTS period is intended for security fixes, but could include few bug fixes as well. ** We will review security vulnerabilities reported to the (tw:Security Team)) ** Publish a or a way to deactivate the feature. *** If the included doesn't have a patch for that version * What if a security vulnerability requires major code , that are not suitable for LTS? ** We'll disable the feature via ((doc:System Configuration)) so you can can choose to use it knowing the risks decide not to use it, or upgrade. * The documentation at doc.tiki.org is kept up to date for more recent versions, so expect see there some documentation features not available in your Tiki. !! Other notes * If you're working on ((Cypht integration|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' 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)). * There are some things that are black and white and there are many shades of gray In case of doubt, ask on (( Mailing List)) * ://trunkbaseddevelopment.com/ !! Related * ((Commit Tags)) ((Git Workflow)) * ((Commit Guidelines)) * ((Backport guidelines)) * ((Git cherry-pick)) |
| Alias names of this page: | Alias names of this page: | ||
| - | (alias(WhereToCommit)) | + | (alias(WhereToCommit)) | (alias(Where)) |
History
| Information | Version | ||||||
|---|---|---|---|---|---|---|---|
| 16 Jul 26 14:22 UTC Benoit Grégoire | 397 | ||||||
| 18 Mar 26 01:05 UTC bienvenu ushindi Update Where to Commit section | 396 | ||||||
| 27 Feb 26 15:45 UTC Benoit Grégoire | 395 | ||||||
| 27 Feb 26 15:43 UTC Benoit Grégoire Emphasise that backports shouldn't be automatic... | 394 | ||||||
| 06 Feb 26 12:44 UTC bienvenu ushindi | 393 | ||||||
| 19 Nov 25 14:14 UTC Benoit Grégoire Update for release of Tiki 29.0 | 392 | ||||||
| 24 Sep 25 11:07 UTC Marc Laporte Label name update | 391 | ||||||
| 18 Sep 25 15:17 UTC luci | 390 | ||||||
| 29 Aug 25 14:52 UTC Benoit Grégoire | 389 | ||||||
| 29 Aug 25 14:51 UTC Benoit Grégoire | 388 | ||||||
| 24 Jul 25 20:32 UTC Rodriguez Nyiringabo Fix | 387 | ||||||
| 24 Jul 25 20:19 UTC Rodriguez Nyiringabo Fix | 386 | ||||||
| 24 Jul 25 20:12 UTC Rodriguez Nyiringabo Fix error | 385 | ||||||
| 24 Jul 25 10:36 UTC bienvenu ushindi | 384 | ||||||
| 24 Jul 25 09:42 UTC bienvenu ushindi | 383 | ||||||
| 18 Nov 24 13:47 UTC Marc Laporte | 382 | ||||||
| 18 Nov 24 13:45 UTC Marc Laporte Adding a section for exceptions | 381 | ||||||
| 16 Nov 24 15:11 UTC Baraka Kinywa Fix typo Approuve => Approve | 380 | ||||||
| 15 Nov 24 22:25 UTC benjamin.shako Document how to comment on tasks on gitlab to ensure collaboration | 379 | ||||||
| 27 Oct 24 00:11 UTC Rodriguez Nyiringabo | 378 | ||||||
| 12 May 24 16:43 UTC lindon Use ~|~ table cell separators for the table body to avoid pipes in links being interpreted as table cell dividers | 377 | ||||||
| 22 Apr 24 13:47 UTC Benoit Grégoire Update after branching | 376 | ||||||
| 08 Apr 24 12:31 UTC Benoit Grégoire | 375 | ||||||
| 04 Jan 24 22:05 UTC Benoit Grégoire | 374 | ||||||
| 03 Oct 23 09:51 UTC Lupundu Kalekwa Yan | 373 | ||||||