Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DTP Development Guidelines"

 
Line 8: Line 8:
 
** 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.
 
** 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''.
 
** 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 ''manifest.mf'' descriptor) must also include a version tolerance specification.
 +
 +
==Non-reoccurring Items==
 +
 +
* Manifest file usage: All DTP 1.0 plug-ins must use a ''manifest.mf'' 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 ''Eclipse.org'' 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.

Revision as of 12:20, 2 October 2006

Introduction

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 build.properties 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 manifest.mf descriptor) must also include a version tolerance specification.

Non-reoccurring Items

  • Manifest file usage: All DTP 1.0 plug-ins must use a manifest.mf 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 Eclipse.org 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