Skip to main content
Jump to: navigation, search

DTP Development Guidelines


The purpose of this page is to collect DTP 1.0 work items in a convenient list for reference by DTP committers and especially DTP project leads. This list contains both reoccurring and non-reoccurring work items. Reoccurring work items are those which require action a multiple times during the project, while non-reoccurring work items are completed by being addressed once.

Reoccurring Items

  • Plug-in version updates: When any change to a plug-in is made, regardless of whether the change is to source code or other project elements, the last (fourth place) number in the plug-in version must be updated as well. For DTP, this almost always means updating the version in the files as well. Details as follows:
    • Why? Because otherwise there is no easy way of determining which plug-ins have changed between builds based on the binary distributions.
    • Version format: major.minor.service.date_stamp. The date_stamp is what should be updated with each plug-in change. The format for this is YearMonthDateBuildIteration. For example, if the current date is October 2, 2006, then the date_stamp is 200610021. The reason for the BuildIteration number at the end of the date_stamp (in the example, it is 1), is so we can accomodate multiple plug-in changes on one day. Thus, the second change to a plug-in on October 2, 2006 would result in a date_stamp of 200610022. This BuildIteration flag is particularly important near release time, when multiple builds per day might be posted to address major bugs.
    • Do not update any other version fields unless you obtain permission from dtp-pmc (that is, at least 2 "yes" votes). In the future, a more comprehensive versioning plan for DTP will provide policies governing the update other fields other than date_stamp.
  • Version Tolerance Specifications for Dependencies: All plug-ins that any DTP plug-in depends on (as specified in the descriptor) must also include a version tolerance specification.

Non-reoccurring Items

  • Manifest file usage: All DTP 1.0 plug-ins must use a descriptor.
  • About file inclusion: All DTP 1.0 plug-ins must include the approved about.html file.
  • Plug-in and Vendor Names: All DTP 1.0 plug-ins must use as the vendor name reported in the Eclipse About... dialog. The plug-in name and description should be consistent with other DTP 1.0 plug-ins. As always, ask dtp-pmc if there is any doubt.

Back to the top