Jump to: navigation, search

DTP Development Guidelines

Revision as of 11:14, 2 October 2006 by John.graham.sybase.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


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.