Free cookie consent management tool by TermsFeed Policy Generator

Changes between Version 4 and Version 5 of Documentation/DevelopmentCenter/DeveloperGuidelines


Ignore:
Timestamp:
09/30/08 01:19:59 (16 years ago)
Author:
swagner
Comment:

minor changes

Legend:

Unmodified
Added
Removed
Modified

  • Documentation/DevelopmentCenter/DeveloperGuidelines

    v4 v5  
    3737
    3838=== Guidelines for Plugin Names ===
    39  * the name of a plugin has to be identical to the project name and the namespace of the plugin
     39 * the name of a plugin has to be identical to the project name and the namespace of the plugin (e.g. `HeuristicLab.Data`)
    4040 * the name of each HeuristicLab 3 plugin starts with "`HeuristicLab.`"
    41  * in order to structure plugins hierarchically, sub-namespaces can be used (`HeuristicLab.Operators`, `HeuristicLab.Operators.Programmable`, e.g.)
    42  * each plugin is represented as a component in trac
    43  * for trac component names the leading "`HeuristicLab.`" is omitted
     41 * in order to structure plugins hierarchically, sub-namespaces can be used (e.g. `HeuristicLab.Operators` and `HeuristicLab.Operators.Programmable`)
     42 * each plugin is represented as a component in Trac
     43 * for Trac component names the leading "`HeuristicLab.`" is omitted
    4444
    4545----
    4646
    4747== Versioning System ==
    48 Source code and other documents are kept in a Subversion repository available at [https://sources.heuristiclab.com/hl3/core https://sources.heuristiclab.com/hl3/core]. Anonymous read-only access is available using the user name and password "anonymous". If you want to contribute to the HeuristicLab project and need write access, please contact stefan.wagner@heuristiclab.com. All HeuristicLab developers have full write access to the whole repository.
     48Source code and other documents are kept in a Subversion repository available at [https://sources.heuristiclab.com/hl3/core https://sources.heuristiclab.com/hl3/core]. Anonymous read-only access is available using the user name and password "anonymous". If you want to contribute to the HeuristicLab project and need write access, please write an e-mail to [mailto:support@heuristiclab.com support@heuristiclab.com]. All HeuristicLab developers have full write access to the whole repository.
    4949
    5050For an introduction to Subversion, please take a look at the free book [http://svnbook.red-bean.com/ Version Control with Subversion] and the [http://tortoisesvn.net/docs/release/TortoiseSVN_en/index.html Online Dokumentation] of the Subversion client [http://tortoisesvn.net/ TortoiseSVN].
    … …  
    5656     * contains all project documentation files (API documentation, license, presentations, etc.)
    5757   * `setup`
    58      * contains all files to build the HeuristicLab installation executable
     58     * contains all files to build the HeuristicLab installer
    5959   * `sources`
    6060     * `HeuristicLab.sln`
    … …  
    7676       * are used to prepare release versions
    7777       * are used to store old versions of plugins
    78        * the folder name of a release branch has to be identical to the major and minor version number (3.1, 3.2, e.g.) (cf. [wiki:DevelopmentGuidelines#Versioning Versioning])
     78       * the folder name of a release branch has to be identical to the major and minor version number (e.g. 3.1) (cf. [wiki:DevelopmentGuidelines#Versioning Versioning])
    7979 * `tags`
    80    * contain a folder for each finally release version (tag)
     80   * contain a folder for each HeuristicLab release bundle (tag)
    8181   * it's not allowed to commit to tags
    8282   * the folder name of a tag has to be identical to the whole version number (e.g. 3.1.0.304) (cf. [wiki:DevelopmentGuidelines#Versioning Versioning])
    … …  
    8787   * each commit has to have a description (commit message)
    8888   * WikiFormatting has to be used to format commit messages
    89    * each commit message must contain the ticket number of the corresponding trac ticket (e.g. "(!#1)")
     89   * each commit message must contain the ticket number of the corresponding Trac ticket (e.g. "(!#1)")
    9090 * repository content
    9191   * the repository has to contain all files necessary for compiling HeuristicLab
    92    * automatically generated files are not stored in the repository. This especially includes:
    93      * object files, assemblies, etc. ()
    94      * generated files (e.g. !AssemblyInfo.cs)
     92   * automatically generated files (object files, assemblies, !AssemblyInfo.cs, etc.) are not stored in the repository
    9593   * files containing user specific settings are not stored in the repository (e.g. *.suo, *.user)
    96    * the SVN property `svn:ignore` has to be set to prevent that files are added accidentally. Predefined property values for solution, project, and properties folders are attached to this page and can be imported
     94   * the SVN property `svn:ignore` has to be set to prevent that files are added accidentally (predefined property values for solution, project, and properties folders are attached to this page and can be imported)
    9795 * branches and tags
    9896   * each developer can create a new exploration branch at any time
    99    * new release branches for a plugin can be crated by the head developer of a plugin only
     97   * new release branches for a plugin can be crated by the head developer of that plugin only
     98   * new tags are created by the head developer of HeuristicLab only
    10099
    101100----
    … …  
    107106   * when incrementing the major version number of a plugin, the minor version number has to be set back to 0
    108107   * the major and minor version numbers have to be included in the assembly name of each HeuristicLab assembly (e.g. `HeuristicLab.Data-3.2.dll`)
    109    * all major and minor versions of a plugin are kept in order to assure backwards compatibility
     108   * all major and minor versions of a plugin are kept in the repository and have to be functional in order to assure backwards compatibility
    110109 * `Build`
    111110   * the build number is used to identify different versions within the same major and minor version of a plugin
    112111   * for each new version (major or minor version number increment), the build number has to be set back to 0
    113112   * all builds within the same major and minor version are considered to be "functionally equivalent"
    114    * all builds within the same major and minor version have to be compatible concerning data files (XML serialization)
     113   * all builds within the same major and minor version have to be compatible concerning data files
    115114 * `Revision`
    116115   * represents the last revision, in which the component (assembly) has been changed or in which a version has been released
    117116   * when compiling assemblies the revision number is automatically extracted from the Subversion repository (cf. [wiki:DevelopmentGuidelines#SubWCRev Automatic Extraction of the Current Revision Number])
    118    * when creating a new release of the whole system (tag) the revision number has to be set manually
     117   * when creating a new release bundle of the whole HeuristicLab system (tag) the revision number has to be set manually
    119118
    120119=== Automatic Extraction of the Current Revision Number === #SubWCRev
    121 The tool [http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html SubWCRev] of TortoiseSVN is used to extract the revision number of the last change of a plugin. SubWCRev is executed by the command [source:trunk/PreBuildEvent.cmd PreBuildEvent.cmd] which has to be set as pre-build event in each project in the following way
     120The tool [http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html SubWCRev] of TortoiseSVN is used to extract the revision number of the last change of a plugin. SubWCRev is executed by the command [source:trunk/PreBuildEvent.cmd PreBuildEvent.cmd] which has to be set as pre-build event in each project in the following way:
    122121{{{
    123122 cmd /c ""$(SolutionDir)PreBuildEvent.cmd" "$(ProjectDir).""
    124123}}}
    125 SubWCRev replaces the placeholder `$WCREV$` in the frame file `AssemblyInfo.frame` of the project by the corresponding revision number and creates the file `AssemblyInfo.cs`.
     124SubWCRev replaces the placeholders `$WCREV$` and `$WCNOW$` in the frame file `AssemblyInfo.frame` of the project and creates the file `AssemblyInfo.cs`.
    126125
    127126----
    128127
    129128== Issue Tracking ==
    130 The issue tracking system [http://trac.edgewall.org/ Trac ] is used to manage the HeuristicLab development process. The HeuristicLab trac environment is available at [https://sources.heuristiclab.com/trac/hl3/core https://sources.heuristiclab.com/trac/hl3/core]. User credentials are identical to those of the Subversion repository. For anonymous access the user and password "anonymous" can be used.
     129The issue tracking system [http://trac.edgewall.org/ Trac] is used to manage the HeuristicLab development process. The HeuristicLab Trac environment is available at [https://sources.heuristiclab.com/trac/hl3/core https://sources.heuristiclab.com/trac/hl3/core]. User credentials are identical to those of the Subversion repository. For anonymous access the user and password "anonymous" can be used.
    131130
    132 Further information about trac can be found in the [wiki:TracGuide Trac User and Administration Guide].
     131Further information about Trac can be found in the [wiki:TracGuide Trac User and Administration Guide].
    133132
    134 === Guidelines for Working with trac ===
     133=== Guidelines for Working with Trac ===
    135134 * all development steps have to be represented by tickets
    136  * before working on a plugin a ticket has to be created and accepted by the developer
     135 * before working on a plugin, a ticket has to be created and accepted by the developer
    137136 * each developer is allowed to assign tickets to other developers, if the ticket is in the responsibility of that developer
    138  * development progress has to be documented by ticket comments. For each commit associated with a ticket, a ticket comment has to be written that contains a link to the revision (e.g. "(!r304)") and a short description. In combination with the link to the ticket in the commit message, this results in a bijective association of tickets and revisions.
     137 * development progress has to be documented by ticket comments
     138 * for each commit associated with a ticket, a ticket comment has to be written that contains a link to the revision (e.g. "(!r304)") and a short description (in combination with the link to the ticket in the commit message, this results in a bijective association of tickets and revisions)
    139139 * each commit has to be associated with a single ticket
    140140
    … …  
    146146       * tickets that are assigned to another developer get the status `assigned`
    147147     * `accepted`
    148        * tickets that are currently processed by a developer get the status `accepted`. The ticket status has to be set manually by the developer before starting to work on the ticket. If working on a ticket is suspended for a longer period of time without closing the ticket, the status has to be reset to `assigned`. In that way it is assured that accepted tickets represent exactly those tickets, on which developers are currently working.
     148       * tickets that are currently processed by a developer get the status `accepted`
     149       * the ticket status has to be set manually by the developer before starting to work on the ticket
     150       * if working on a ticket is suspended for a longer period of time without closing the ticket, the status has to be reset to `assigned` (in that way it is assured that accepted tickets represent exactly those tickets, on which developers are currently working)
    149151     * `closed`
    150        * tickets which are resolved get the status `closed`. The developer has to provide an explanation for closing the ticket.
    151        * possible resolutions for closing a ticket are `fixed` (work done), `invalid` (ticket), `wontfix` (ticket will not be resolved), `duplicate` (another ticket has already been created for that issue), `worksforme` (issue could not be reproduced).
    152        * when closing a ticket with another explanation as `fixed`, the developer has to provide a comprehensive explanation in form of a ticket comment
     152       * tickets which are resolved get the status `closed`
     153       * developers have to provide an explanation for closing a ticket
     154       * possible resolutions for closing a ticket are `fixed` (work done), `invalid` (invalid ticket), `wontfix` (ticket will not be resolved), `duplicate` (another ticket has already been created for that issue), `worksforme` (issue could not be reproduced)
     155       * when closing a ticket with another explanation as `fixed`, the developer has to provide a comprehensive explanation
    153156     * `reopened`
    154        * when a ticket is reopened again, the status is set to `reopened`. Thereby the responsible developer is removed. The ticket has to be assigned again.
     157       * when a ticket is reopened again, the status is set to `reopened`
     158       * when reopening a ticket, the responsible developer is removed and the ticket has to be assigned again
    155159   * Type
    156160     * `defect`
    … …  
    163167       * other (administrative) tasks which are not associtated with programming directly (e.g. generating documentation, creating release branches, etc.)
    164168   * Priority
    165      * the following priorities are available to classify tickets: `blocker` (priority 1), `critical` (priority2), `major` (priority3), `minor` (priority4), `trivial` (priority5).
    166      * classification of a ticket's priority has to be done by the user who reported the ticket
     169     * the following priorities are available to classify tickets: `blocker` (priority 1), `critical` (priority 2), `major` (priority 3), `minor` (priority 4), `trivial` (priority 5)
     170     * classification of a ticket's priority has to be done by the user who reports the ticket
    167171   * Milestone
    168172     * a ticket has to be associated with a milestone
    169      * milestones represent phases of the development of HeuristicLab. Usually a milestone is associated with the version of a HeuristicLab release bundle.
     173     * milestones represent phases of the development of HeuristicLab
     174     * usually a milestone is associated with the version of a HeuristicLab release bundle
    170175   * Component
    171      * a ticket has to be associated with a component (a plugin)
     176     * a ticket has to be associated with a component (i.e. a plugin)
    172177     * the name of a component has to be identical to the name of the namespace or the plugin of that component (the leading "`HeuristicLab.`" is omitted)
    173178   * Version
    … …  
    179184== Documentation ==
    180185=== Wiki ===
    181 The trac wiki system is used for documenting the development of HeuristicLab. A description of the trac wiki syntax is available at WikiFormatting.
     186The Trac wiki system is used for documenting the development of HeuristicLab. A description of the Trac wiki syntax is available at WikiFormatting.
    182187
    183188=== Source Code ===