Loading...
 

History: Where to commit

Comparing version 273 with version 374

Lines: 1-143Lines: 1-125
-{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



Dashboard
! DashboardQuick overview intended to help to know where to commit to right now in most situations. See [#Branches| Branches section] below for


detailed explanations.


{BOX(title="Current status" align="left")}* __Automatic merging is ongoing__ (a.k.a. ((Semi-automatic

period)))
** Fixes and translations ''only'' to go into 20.x first, any enhancements

to go in
trunk/master
** 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
, and then to 18.x and finally to 15.x. For more

, see the table below.
** During this period, changes to trunk/master increase the risks of ((merge conflicts)). To minimize this risk
, non-functional changes (e.g. code formatting, code documentation and other refactoring) which are not specific to trunk/master only and which can be postponed should be avoided. ''In particular, automated code reformatting in batch (many files at

) should be postponed.''
~tc~*
All commits need to start in trunk/master** For example if you want to make a fix to 12.x LTS, please commit the fix to trunk/master first then backport to 18.x, and then to 15.x and finally to 12.x. For more details,

see
the table below.

/tc~
* __Upcoming releases__:
** ''20.
, 19.2, 18.4 LTS, 15.8 LTS and 12

15 LTS will be
the next versions released.''
{BOX}
+{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, 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
 Commit status and order for each open branch: Commit status and order for each open branch:
-{FANCYTABLE(head="__I want to commit to:__ | __What is allowed:__ | __Commit first to:__ | __Afterwards , backport to:__")}__trunk/master__ (future 21x) | Functional enhancements, new features | |

__20x__ | Fixes and translations only | | 19x
x__19x__ | Fixes and translations only (during 20.0 freeze) | trunk | x
.x__18x__ | Fixes and translations only LTS | 19.x |x
15
.x__15x__ | Fixes only LTS |18.xx
12.x__12x__ | Critical fixes only LTS | 15.x|
+{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. 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 (

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/24.x|branches/24.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__ |[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}
-The other branches are closed, and no releases are planned. So there is no point in committing there. +Legend:

*
STS: Standard Term


* LTS: Long Term Support
-! Branches Again

''Root
:'' [https://svn.code.sf.net/p/tikiwiki/code/]
+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)).
-||''Name''|''BRANCH''|''Comments''

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
be functional, but don't need to be complete. In theory, should be releasable at any time. This is the place for refactoring. Cosmetic code changes should be done here.~tc~ after the ((Semi-automatic merging period)) has ended.~/tc~ %%% 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 trunk/master, and after you want to commit to a stable branch, please see how to ((Merge a commit from trunk|merge a commit from trunk/master))


__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))
-! Definition of "security-only" phase

* The "security-only" of the LTS period is intended for security fixes, but could include a few bug fixes as well


** We will review security vulnerabilities reported to the
((tw:Security Team

)
**
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, that are not

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

, 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: ((tw:Versions)) and ((Git Workflow)).
-! Other notes

* 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
, a fix to a feature that was removed later). See [Quality+Team#What_will_be_considered|here] for more info


* 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
things and increases possibilities for errors.__ If you must, please see: ((Database Schema

))
* 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

))
* If we are close
to a release, and you have a change with a risk of regression, try to consult the [http://tiki.org/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 the (

Dev Mailing List))
* https://trunkbaseddevelopment
.com/
+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.
-! Legacy
__There are no more planned releases
of versions prior to 12, as well as versions 13, 14, 16 and 17.__ If you are running one and commit a fix , please merge manually your fix to the appropriate branch.
+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).
-!- Examples +!! The commit process (the human part)
-Based on changelog review notes since 2.0RC1 +!!! 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

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)
.
-Participants:

*



*

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*
-{CODE(wrap=>1)}

r13615
| jonnybradley | 2008-07-12 15:13:38 -0400 (Sat, 12 Jul 2008) | line
lineChanged

:
M
/branches/2.
/templates/remarksbox.tpl
+!!! 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
-[FIX] {remarksbox} layout improvements 
-{CODE} 
-* This is not a fix or a security issue. Minor code improvements should be made in trunk/master. +!! Collaborating
-{CODE(wrap=>1)}

r13613 | jonnybradley | 2008-07-12 11:40:20 -0400 (Sat, 12 Jul 2008) | lines
linesChanged


:
M /branches/2.
/templates/tiki
-editpage.tpl M /branches/2.
/tiki
-editpage.php M /branches/2.
/tiki-parsemode_setup
.php
+# 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} 
-* __ROLLBACK__

* 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
-{CODE(wrap=>1)}

r13612
| jonnybradley | 2008-07-12 10:49:47 -0400 (Sat, 12 Jul 2008) | lines
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
-[FIX] Removing document.write() calls for "Select All" checkboxes (because document.write is evil)

This will result in some non-functioning checkboxes appearing now for people with JavaScript disabled where they didn't b
before, but this was only on about half of these type of

.
If it's important (still?) these should all be surrounded with {if $javascript_enabled} checks but at the moment g
var only gets set for people with
$prefs['pref_syntax']=='1.9' (

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]."
-* __ROLLBACK__

*
See ricks' comments
+!!! Risk assessment: Keep context in mind.
-{CODE(wrap=>1)}

r13606 | sylvieg | 2008-07-11 17:18:03 -0400 (Fri, 11 Jul 2008) | line
lineChanged

:
M /branches/2.
/templates/tiki
-edit_banner.tpl
+## 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.
-title

{CODE}
+!!! 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.
-* Simple code enhancements, should be made in trunk/master 
-{CODE(wrap=>1)}

r13600 | pkdille | 2008-07-11 16:44:40 -0400 (Fri, 11 Jul 2008) | line
lineChanged

:
M /branches/2.
/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)) 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 the ((Dev Mailing List))
* https:
//trunkbaseddevelopment.com/
-[UI FIX] objectperms: switch perms and perms descriptions

{CODE


* Cosmetic change, should go in trunk/master
+!! Related

*
((Commit Tags)


* ((Git Workflow

)

* ((Commit

))
* ((

guidelines))
*
((Git cherry-pick))
 Alias names of this page: Alias names of this page:
-(alias(WhereToCommit)) +(alias(WhereToCommit)) | (alias(Where))

History

Advanced
Information Version
04 Jan 24 22:05 GMT-0000 Benoit Grégoire 374
03 Oct 23 09:51 GMT-0000 Lupundu Kalekwa Yan 373
09 Aug 23 23:43 GMT-0000 Marc Laporte Cypht 372
22 Jul 23 23:11 GMT-0000 Marc Laporte Clarifying who has powers 371
20 Jul 23 16:20 GMT-0000 Benoit Grégoire 370
18 Jul 23 21:09 GMT-0000 Benoit Grégoire Merge advice to reviewer 369
08 Jul 23 16:17 GMT-0000 Marc Laporte Alternate process 368
08 Jul 23 04:48 GMT-0000 Marc Laporte Introduce the abbreviation a few times, and then use it as much as possible 367
08 Jul 23 04:38 GMT-0000 Marc Laporte Database is important, so putting higher on page 366
08 Jul 23 04:33 GMT-0000 Marc Laporte Removing as this is implicit from above 365
08 Jul 23 04:31 GMT-0000 Marc Laporte cleaner 364
08 Jul 23 04:20 GMT-0000 Marc Laporte 363
08 Jul 23 04:18 GMT-0000 Marc Laporte 362
08 Jul 23 04:16 GMT-0000 Marc Laporte 361
08 Jul 23 04:12 GMT-0000 Marc Laporte 360
08 Jul 23 04:10 GMT-0000 Marc Laporte 359
08 Jul 23 04:06 GMT-0000 Marc Laporte cleanup 358
08 Jul 23 03:56 GMT-0000 Marc Laporte 357
08 Jul 23 03:46 GMT-0000 Marc Laporte 356
08 Jul 23 03:25 GMT-0000 Marc Laporte 355
08 Jul 23 03:18 GMT-0000 Marc Laporte 354
08 Jul 23 03:17 GMT-0000 Marc Laporte 353
08 Jul 23 03:17 GMT-0000 Marc Laporte 352
08 Jul 23 03:14 GMT-0000 Marc Laporte 351
08 Jul 23 03:13 GMT-0000 Marc Laporte 350

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Diagram
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw -superseded by Diagram
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Gantt
Group
Groupmail
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Kanban
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend
Terms and Conditions
Theme
TikiTests
Federated Timesheets
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools