 |
- Author:
- larsivi (IP: 84.48.50.144)
- Timestamp:
- 01/27/08 15:12:53 (16 years ago)
- Comment:
--
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ReleaseProcess
| v3 |
v4 |
|
| | 1 | [[TOC()]] |
|---|
| 1 | 2 | = Release Process = |
|---|
| 2 | 3 | |
|---|
| 3 | | '''TODO''': Figure out how to integrate compiler releases into this document. It is possible that two axis of releases are needed. If the compiler writers decides to cooperate, the most sane way would probably be for them to make a patch set towards the current stable release, do a beta release, then make a library release with this patch set incorporated. |
|---|
| 4 | | |
|---|
| 5 | | To make sure a release happen as smoothly as possible, we should strive to follow the process description below. |
|---|
| | 4 | To make sure a release happen as smoothly as possible, we should strive to follow the process description below. However, this being an open source project with fairly restricted resources, certain aspects, especially related to feature freeze and documentation, tend to be ignored to make timely releases at all possible. |
|---|
| 6 | 5 | |
|---|
| 7 | 6 | * The [wiki:QAProcessLibraryRelease QA Process] is an important prerequisite in this process and must be followed prior to making a release. |
|---|
| 9 | 8 | == Release schedule == |
|---|
| 10 | 9 | |
|---|
| 11 | | The project will make 3 types of releases, major, feature and bugfix. |
|---|
| | 10 | The project may make 3 types of releases, major, feature and bugfix. |
|---|
| 12 | 11 | |
|---|
| 13 | 12 | * Major releases will be denoted by incrementation of the first version number, ie from 1.1 to 2.0, and will consist of bugfixes, feature additions and possibly breaking changes and deprecations. |
|---|
| 35 | 34 | * No breaking rewrites or deprecations will be considered. |
|---|
| 36 | 35 | * When the proposed feature list is ready, a tentative date for the next release will be decided upon. |
|---|
| 37 | | * 4 weeks prior to release, a feature freeze will be announced. |
|---|
| | 36 | * 2 weeks prior to release, a feature freeze will be announced. |
|---|
| 38 | 37 | * English documentation should be finalized by feature freeze. |
|---|
| 39 | 38 | * Eventual translations of documentation should start at feature freeze and continue towards release. |
|---|
| 52 | 51 | * Tango will be packaged, and put up for download. |
|---|
| 53 | 52 | * A release announcement will be released to all applicable receivers. |
|---|
| | 53 | |
|---|
| | 54 | == Effect of compiler releases == |
|---|
| | 55 | |
|---|
| | 56 | Generally, this should not be a problem, except for cases where a change in the compiler/runtime interface has occurred for a given compiler release, where that leads to newer Tango code not being compilable or linkable with compiler older than the new version in question. If that happens, the following things should be done: |
|---|
| | 57 | |
|---|
| | 58 | * New Tango release should mark the new compiler version as a minimum requirement |
|---|
| | 59 | * The last revision prior to commit of the new interface should be tagged |
|---|
|
 |
 |
|
 |
Copyright © 2006-2024 Tango. All Rights Reserved. | Page Width:
Static or
Dynamic
