Difference between revisions of "MWS"
(don't confuse Master Workspace and milestone) |
(Reworked the complete text) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | MWS is the abbreviation for "MasterWorkSpace". OpenOffice.org knows to 2 kind of MWSs: | |
| − | |||
| − | |||
| − | + | * [[DevelopmentCodeline|Development codeline]] which is named DEV300. This is (kind of) unstable and will never end in a release. | |
| + | * [[ReleaseCodeline|Release codeline]] which is named like its release (e.g., OOO320 for OOo 3.2.0). Every [[Product_Release|feature release]] has its own MWS. | ||
| − | |||
| − | |||
| − | |||
| − | When | + | When moving forward for a release then a branch off from DEV300 to a new MWS will be done. From a MWS all new [[ChildWorkSpace|ChildWorkSpaces]] (CWS) are branched off. |
| − | + | Physically the MWS corresponds to the trunk of a main [[Mercurial|HG]] (Mercurial) branch. If you download a [http://download.openoffice.org/next/ Developer Snapshot] or a [http://download.openoffice.org/ OOo release], these builds are always created from a MWS. | |
| + | |||
| + | The idea behind MWS/CWS is that no development is directly done on a MWS. Instead all work is performed on a copy of the respective MWS. This copy then is referred to as a CWS. Only if the CWS is at least as good as the MWS (it may contain no regressions and all newly introduced features must be fully operational) it will be [[Merging|merged]] ([[Integration|integrated]]) into the MWS. Ideally this would mean that the MWS can be released at any time as a fully working drop. However, this only works in theory. Still the concept of MWS/CWS greatly reduces the number of new issues compared with a development only and directly in the MWS. | ||
| + | |||
| + | The idea behind branching off the development codeline to a release codeline is that the developers can do both: a) to work on stabilizing the code when going forward to a new release and b) to implement new things that do not belong to the upcoming release but to future versions. | ||
| + | |||
| + | When a CWS is created for a release MWS, this CWS will be cloned and integrated into the development MWS as well. This is to ensure that all fixes for the upcoming release are put into the development codeline as well. | ||
| + | |||
| + | [[Category:Quality Assurance]] | ||
Latest revision as of 16:32, 5 July 2010
MWS is the abbreviation for "MasterWorkSpace". OpenOffice.org knows to 2 kind of MWSs:
- Development codeline which is named DEV300. This is (kind of) unstable and will never end in a release.
- Release codeline which is named like its release (e.g., OOO320 for OOo 3.2.0). Every feature release has its own MWS.
When moving forward for a release then a branch off from DEV300 to a new MWS will be done. From a MWS all new ChildWorkSpaces (CWS) are branched off.
Physically the MWS corresponds to the trunk of a main HG (Mercurial) branch. If you download a Developer Snapshot or a OOo release, these builds are always created from a MWS.
The idea behind MWS/CWS is that no development is directly done on a MWS. Instead all work is performed on a copy of the respective MWS. This copy then is referred to as a CWS. Only if the CWS is at least as good as the MWS (it may contain no regressions and all newly introduced features must be fully operational) it will be merged (integrated) into the MWS. Ideally this would mean that the MWS can be released at any time as a fully working drop. However, this only works in theory. Still the concept of MWS/CWS greatly reduces the number of new issues compared with a development only and directly in the MWS.
The idea behind branching off the development codeline to a release codeline is that the developers can do both: a) to work on stabilizing the code when going forward to a new release and b) to implement new things that do not belong to the upcoming release but to future versions.
When a CWS is created for a release MWS, this CWS will be cloned and integrated into the development MWS as well. This is to ensure that all fixes for the upcoming release are put into the development codeline as well.
