Author: Derick Rethans Date: 2007-01-10 16:09:54 +0100 (Wed, 10 Jan 2007) New Revision: 4484
Log: - Fix speling mistakes. Modified: docs/dev_process.txt docs/guidelines/design_doc.txt docs/guidelines/requirements_doc.txt docs/guidelines/review.txt docs/guidelines/tutorial.txt docs/guidelines/versioning.txt Modified: docs/dev_process.txt =================================================================== --- docs/dev_process.txt 2007-01-10 14:28:42 UTC (rev 4483) +++ docs/dev_process.txt 2007-01-10 15:09:54 UTC (rev 4484) @@ -148,7 +148,7 @@ After the implementation of the classes there is a review required of the implementation. The review should be done by at least two people that where *not* part in writing the code. The original author is of course free to do a -review as well. During the review the implemention should be matched against +review as well. During the review the implementation should be matched against the requirements specification and design document. On top of there a few extra thing should be taken care of, which are described in the `review`_ document. @@ -189,7 +189,7 @@ *I have no idea what this should entail* -Applicibility +Applicability ------------- New Components Modified: docs/guidelines/design_doc.txt =================================================================== --- docs/guidelines/design_doc.txt 2007-01-10 14:28:42 UTC (rev 4483) +++ docs/guidelines/design_doc.txt 2007-01-10 15:09:54 UTC (rev 4484) @@ -28,7 +28,7 @@ Format of the document ====================== -To ensure consistensy the following format should be employed in the +To ensure consistency the following format should be employed in the document. The document should always start with a header which says:: eZ component: Component, Design @@ -47,9 +47,9 @@ Design description ------------------ -Explain the main ideas behind the design, this is usally more details from the +Explain the main ideas behind the design, this is usually more details from the requirements and design goals. The design should list all the classes using -subheaders and give a description of the class and their purpose. :: +sub headers and give a description of the class and their purpose. :: Guidelines ---------- Modified: docs/guidelines/requirements_doc.txt =================================================================== --- docs/guidelines/requirements_doc.txt 2007-01-10 14:28:42 UTC (rev 4483) +++ docs/guidelines/requirements_doc.txt 2007-01-10 15:09:54 UTC (rev 4484) @@ -38,7 +38,7 @@ Format of the document ====================== -To ensure consistensy the following format should be employed in the +To ensure consistency the following format should be employed in the document. The document should always start with a header which says:: eZ component: Component, Requirements @@ -75,7 +75,7 @@ This must explain the requirements of the package as seen from the end user or external developers point of view. The requirements must not be technical or -mention design og implemenation details (unless it really relates to it). Using +mention design and implementation details (unless it really relates to it). Using a bullet list for the requirements can be a good idea. It is important that everything that the component should solved is mentioned here, it should not be up to the designer or implementer to add extra features. @@ -85,7 +85,7 @@ ============ Based on the requirements some design goals should be explained. These goals -are more technical and detailed without resorting to specfying the design +are more technical and detailed without resorting to specifying the design itself. This is usually not of interest to the end user but might be useful for the external developers, class designers and implementors. :: @@ -110,7 +110,7 @@ To clarify the requirements text it might be a good idea to include UML diagrams or other diagrams which help the reader to understand the component. Useful diagrams are use-case for examples, component diagrams for basic -structure and activity diagrams for workflows. +structure and activity diagrams for work flows. .. Modified: docs/guidelines/review.txt =================================================================== --- docs/guidelines/review.txt 2007-01-10 14:28:42 UTC (rev 4483) +++ docs/guidelines/review.txt 2007-01-10 15:09:54 UTC (rev 4484) @@ -16,7 +16,7 @@ (if it can be a float or integer), "string", "array", "array(<type)", "<objectname>" or "resource". - The documentation is not to have any warnings anymore -- See for proper docblocks: +- See for proper doc blocks: http://lists.ez.no/pipermail/components/2005-October/000491.html Parameters Modified: docs/guidelines/tutorial.txt =================================================================== --- docs/guidelines/tutorial.txt 2007-01-10 14:28:42 UTC (rev 4483) +++ docs/guidelines/tutorial.txt 2007-01-10 15:09:54 UTC (rev 4484) @@ -9,7 +9,7 @@ Format of the document ====================== -To ensure consistensy the following format should be employed in the +To ensure consistency the following format should be employed in the document. The document should always start with a header which says:: eZ components: Component @@ -27,7 +27,7 @@ ============ The introduction should explain what the component does, and what it can not -do. Also explain for which things this component can be used for - preferrably +do. Also explain for which things this component can be used for - preferably with a small example (no code, just text). :: Modified: docs/guidelines/versioning.txt =================================================================== --- docs/guidelines/versioning.txt 2007-01-10 14:28:42 UTC (rev 4483) +++ docs/guidelines/versioning.txt 2007-01-10 15:09:54 UTC (rev 4484) @@ -8,7 +8,7 @@ x major version number, when its 0 the component is a beta component. A - component with major version 0 can never be release publically. When + component with major version 0 can never be release publicly. When the number != 0 then it will only increase when there is a backwards compatible break in the component's API. @@ -16,25 +16,25 @@ minor version number, is used for all feature additions z - mini version number, is used to denote bugfixes only. This third part + mini version number, is used to denote bug fixes only. This third part can also be a string in the set: (alpha, beta1, beta2, betaN, rc1, rc2, rcN) - in that case it shows that the package is a "beta" package, not ready for production. x and y show the version number of the component, the z is an addition showing -the state (beta etc) or which bugfix release it is. +the state (beta etc.) or which bug fix release it is. Examples ======== 0.1.0 - first possible non-publically released version + first possible non-publicly released version 1.0.0 - first publically released version + first publicly released version 1.0.1 - first bugfix release for component version "1.0" + first bug fix release for component version "1.0" 1.3.7 7th bug fix release for version "1.3" - version "1.3" has more features @@ -50,7 +50,7 @@ First production ready release of the "1.4" version. 2.0alpha - Development release of the component, where backward compability is + Development release of the component, where backward compatibility is broken compared to version "1.x". 2.0beta1 -- svn-components mailing list svn-components@lists.ez.no http://lists.ez.no/mailman/listinfo/svn-components
