Loading...
 

Freeze and Slush

This is a draft (more of a collection of ideas than a plan/guideline)


As a growing community, to be efficient, we must have a common understanding of Where to Commit, but we must also get a common understanding of When to commit.

This page will attempt to describe a consensus on when to commit so we can all converge and be ready to release according to the Lifecycle.

See also: Where to commit

Reverse-planning / Work-Back Schedule


This part needs to be much precise

when what
1 month before technical release (feature-freeze) where all translations (with automatic syntax checking) and promotional material can be prepared.
2 months before All minor new features should be in trunk so they can be tested in time for the release.
3 months before All major new features should be in trunk so they can be tested in time for the release.


The big underlying questions:

  • Will it be good enough in time for the next scheduled release?
  • What are the risks of introducing regressions?


The closer we are to the release, the more risk free your contributions should be


In case of doubt, coordinate with release coordinator. These are questions that come to mind:

  • If you do introduce a bug, will we find quickly and will you fix very quickly? (ex.: within 24h) (or are you the dump-and-disappear-and-let-someone-else-cleanup-my-mess type of developer)
  • If you do introduce a bug, is it for something localized (ex: change css for one theme) ? or can it affect everyone (ex.: login process)
  • Are you an experienced developer and you "know" where the risk areas are?
  • Are you affecting a lot of files?
    • Did you test every single file? (mass search and replace sometimes go wrong)
    • Which can make it difficult to review
    • Which can make the merge from stable to trunk more difficult
  • Are you introducing a database change?
    • In general, DB changes should be done early in the process
  • Has this code been used in production for a reasonable time-frame?

Types of changes

Major changes that affect the whole application.

These should be done fairly early in a cycle. So we have several months to iron-out all the issues. A backward-compatibility layer should be provided. Ex.: Permission Revamp, new modules system, etc. It's a good idea to start these in an Experimental branch.

Major change to existing features.

How will upgrades be handled?

New self-contained features

These can arrive quite late. If they are not ready for prime-time, just tag as experimental.

Inspiration

http://live.gnome.org/ReleasePlanning/Freezes

Related


Alias

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