The goal is to document an ideal/typical development calendar for a consultancy, that fits well with Tiki community calendar.
It should answer educate customers on to when they must give dev contracts for new features in order for them to be part of the next version.
Month | Stable version | Next version |
April | Tiki8 in production | |
May | Stable version | Have a test instance where end-users test |
June | Fix bug in stable branch | and develop new features on trunk |
July | Fix bug in stable branch | and develop new features on trunk |
August | Deploy new stable version | |
September | Refine/document | |
October |
See also: Version Lifecycle