Loading...
 

How to release Branching

Create a branch, if you are releasing a major version

This is done only once per major version (4.x, 5.x, 6.x, etc.) about 4-6 weeks before the planned official release of x.0. For minor versions, the work is done in current branch.

From a trunk checkout
php doc/devtools/svnbranch.php branches/7.x


More details on how to create a branch: SVNTips#Handling_branches

1.1.1. Post-branching operations

1.1.2. Make sure the star name picking process is almost over

This star name is needed for the alpha because it is in the path: https://sourceforge.net/projects/tikiwiki/files/

  • In lib/setup/wiki.php, update $profilesLink to the new branch

1.1.2.2. Make new profiles

1.1.2.3. dev.tiki.org

  • Create the new branch page (if not there yet), i.e.: Tiki18
    • Move the current alias from the old branch to the new created one (I'm not sure what that means? luciash d' being )
  • Add the branch as an option for the Tiki Version field in the Bugs & Wish list tracker (category)
  • Update Daily Build (You need to ask Oliver Hertel to add new versions)
  • Update Get code
  • Update Where to Commit
  • Update Semi automatic merging period

1.1.3. packages.tiki.org

Documentation forthcoming: In the mean time, please ask Ricardo
https://gitlab.com/tikiwiki/tiki-packages-build

1.1.3.1. show.tiki.org

As of 2018-10-11, we can't add 19.x because server is PHP 5.6: so this is on hold for now Marc Laporte

  • First add the new branch to the dropdown in templates/trackerinput/showtikiorg.tpl and commit
  • Remember to backport to the version that the actual dev.tiki.org is running
  • On the show server checkout the new branch into usr/local/src/tiki
  • On the show server add the branch to /usr/local/sbin/tim-common BRANCHES="trunk 12.x 13.x"
  • Refresh the instances by calling right away the cron: /usr/local/sbin/tim-cron
  • Once dev.tiki.org updates, it should then work.

Also...

1.1.4. If new branch, update showtikiorg.tpl

If a new branch is created, then you need to manually update a few lines in the branch which is running for dev.t.o at the file:

./templates/trackerinput/showtikiorg.tpl


Search for "12.x", for instance, in that file, and add the corresponding hardcoded cases for the new branch.

Example:

Version: <select name="svntag">
<option selected="selected">trunk</option>
<option>13.x</option>
<option>12.x</option>
</select>
(...)
	<span class="buttonupdate{$field.fieldId}_{$item.itemId}" {if $field.version != 'trunk' && $field.version != '13.x' && $field.version != '12.x'}style="display: none;"{/if}>{button href="#showtikiorg{$field.fieldId}_{$item.itemId}{if isset($context.list_mode)}_view{/if}" _onclick="showtikiorg_process{$field.fieldId}_{$item.itemId}('update');"  _text="{tr}SVN update{/tr}"}</span>
(...)
			if (data.version == '12.x' || data.version == '13.x' || data.version == 'trunk') {
(...)

1.1.4.1. demo.tiki.org

  • Create a site for new version

1.1.4.2. Pre-dogfood servers

  • Each Pre-Dogfood Server should be moved from trunk to the next branch and each site should go through at least 30 minutes of manual testing of the most common operations.
    Ex.: on http://nextdev.tiki.org, someone should try to report a bug, or on http://nextdoc.tiki.org try and add a new page to a structure (even though it all will be overwritten the next day).
    • the instances need to svn switch and refreshed immediately, e.g.
      +svn switch https://svn.code.sf.net/p/tikiwiki/code/branches/13.x .
      +sh setup.sh -n fix
      +php console.php database:update
    • /usr/local/bin/refresh-nxt.sh needs to be updated so the next cron switches to the right branch
    • A couple of days before the release the cronjob to do a full upgrade including DB-sync from live sites must be disabled so that designers and gardeners can test/learn/prepare for the upgrade of the live community sites.
    • After release the /usr/local/bin/refresh-nxt.sh needs to be changed to trunk again and the full upgrade cron job reenabled.

1.1.4.3. Dogfood release policy

See dogfood for general background info on this policy. The general principle is that most of *.tiki.org sites should be running supported versions before they are released while others will keep running with previous version (LTS).

Goals:

  • Reduce the number of issues and collective time spent on these. Issues can be bugs, data corruption, upgrade bugs (that you don't see in a fresh install), etc. in released versions.
  • There is also a promotional goal for this policy as it reassures users that releases have sufficient testing, and it differentiates us from extension-based systems, where the official sites are upgraded to the latest versions a long time after dot zero.
  • Improve the quality / reliability of .0 releases so we can eventually be in a position to shorten the release cycle. Historically, .0 releases have been shaky and too many people where waiting for .1 and that delays everything.
  • Keeping some website running old LTS version is useful in case we need to produce and test security patch or any other correction necessary.


The various *.tiki.org sites collectively have a lot of users & data and cover quite a few features. Power users of these sites are usually quite familiar and can spot a bug or regression (something that stopped working) and report it efficiently.

Some sites are kept at the latest stable version (ex.: doc.tiki.org), while others are kept on the Long Term Support (LTS) versions (ex.: profiles.tiki.org). The list is maintained at Domains.

All sites are generally updated daily with minor revisions in each branch. So if a site is running 9.x LTS, it has the latest pre-released 9.x code. Exception: some legacy sites are kept for historical purposes in old unsupported versions, normally in read-only mode.

When a new major version is coming out, each of the sites identified as latest stable are progressively updated to the new version.

Start with the less critical one (ex.: themes.tiki.org)

  1. Do a thorough check on the Pre-Dogfood Server version (each site should go through at least 30 minutes of manual testing of the most common operations. Ex.: on dev.tiki.org, someone should try to report a bug.)
    • The pre-dogfood servers generally run trunk, but during the pre-upgrade period, they should be switched to the branch
  2. Fix all the bugs and check they are indeed fixed there
  3. Proceed to upgrade (svn switch)
    • Keep previous version available as a snapshot so users can compare and efficiently report any upgrade issues (ex.: legacydev11.tiki.org)
  4. Give a few days to get feedback for newly uncovered issues
  5. And start over the cycle for each sites.


This whole process typically takes 3-5 weeks because of discovery of new issues and the understandable delay to resolve them. Because of this incompressible time factor, it is important to start the dogfood process as soon as possible in the release process (as soon as all bugs are resolved on the pre-dogfood server)

Finding & fixing an issue while in pre-dogfood avoids wasted time and corrupted data on the real sites. Trying to save time by rushing a release just creates more work down the line.

Created by Jonny Bradley. Last Modification: Friday 12 October, 2018 04:01:08 GMT-0000 by Marc Laporte.

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
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Group
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
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, alert + Social Bookmarking
Terms and Conditions
Theme
TikiTests
Timesheet
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