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 Plug-in Versioning Policy"

Line 1: Line 1:
 
{{Back To|name=DTP Main Page|href=Data Tools Platform Project}}
 
{{Back To|name=DTP Main Page|href=Data Tools Platform Project}}
 
==Status==
 
==Status==
[10/29/07]: This document is a ''draft.'' It has not been approved by the DTP PMC and should not be taken as DTP policy.
+
[11/5/07]: This document has been reviewed and approved: it now represents DTP policy.
 
==Introduction==
 
==Introduction==
This document specifies plug-in versioning rules for DTP. That is, a policy for changing plug-in version numbers based on the types of changes made to the plug-in is specified below. We follow generally accepted Eclipse rules in this area, for example the [[Version Numbering | versioning policy for the Eclipse platform]]. It is important that all DTP committers adhere to this policy so tools (such as Eclipse Update Manager) and DTP users can determine the types of changes present between two versions of a given plug-in.
+
This document specifies plug-in versioning rules for DTP. That is, a policy for changing plug-in version numbers based on the types of changes made to the plug-in is specified below. We follow generally accepted Eclipse rules in this area, for example the [[Version Numbering | versioning policy for the Eclipse platform]], and we deviate only slightly as described below in the "Qualifier Field Format" section. It is important that all DTP committers adhere to this policy so tools (such as Eclipse Update Manager) and DTP users can determine the types of changes present between two versions of a given plug-in.
 
==Definitions==
 
==Definitions==
 
*A DTP plug-in version number has four fields, separated by a ".": '''Major.Minor.Service.Qualifier'''
 
*A DTP plug-in version number has four fields, separated by a ".": '''Major.Minor.Service.Qualifier'''

Revision as of 13:13, 12 November 2007

Back to DTP Main Page

Status

[11/5/07]: This document has been reviewed and approved: it now represents DTP policy.

Introduction

This document specifies plug-in versioning rules for DTP. That is, a policy for changing plug-in version numbers based on the types of changes made to the plug-in is specified below. We follow generally accepted Eclipse rules in this area, for example the versioning policy for the Eclipse platform, and we deviate only slightly as described below in the "Qualifier Field Format" section. It is important that all DTP committers adhere to this policy so tools (such as Eclipse Update Manager) and DTP users can determine the types of changes present between two versions of a given plug-in.

Definitions

  • A DTP plug-in version number has four fields, separated by a ".": Major.Minor.Service.Qualifier
  • A major change indicates breakage in API or significant new/reorganization of functionality.
  • A minor change indicates changes visible to users or extenders of DTP.
  • A service change indicates bug fixes.
  • A qualifier change indicates the plug-in has changed.

As with any specification, there is room for interpretation, and each committer's best judgment is required. When in doubt, ask the DTP team/community by creating a bug or message to the DTP dev mailing list.

Fundamental Constraint

Whatever is done to plug-in version numbers following this policy, each update must result in a number that is monotonically increasing. Otherwise, the Eclipse Update Manager will not detect the newer version of the plug-in, and users' DTP installations will be rendered inconsistent. If you believe that the policy expressed herein requires breaking this fundamental constraint, immediately notify the DTP PMC for direction.

Policy

  • The major, minor, and service fields respectively are to be incremented only once per DTP stream release cycle, depending on the type of change as described above. For example, "1.5.0" can go to "1.5.1" during a release cycle, but not "1.5.2" or higher.
  • The qualifier field is to be updated whenever anything delivered in DTP builds for the plug-in is changed.
  • The precedence of the fields is major > minor > service. When a higher precedence field is updated, fields of lower precedence should be reset to 0 ("zero"). Note:
    • The precedence rules mean that the major field can not be reset to 0.
    • The qualifier field is updated separately, and is not simply incremented nor reset to zero (see below).
  • If a field is reset to 0, then it may be incremented again during a release cycle.

Qualifier Field Format

The qualifier field must be "YearMonthDateIteration." For example, if the last update to a plug-in were on October 29, 2007, then the qualifier field would show "200710291." If that same plug-in were updated again on the same calendar day, then the qualifier field would show "200710292."

Initial Version for New Plug-ins

Plug-ins newly added to a DTP release cycle normally will start with a "1.0.0.Qualifier" version number, unless the plug-in is considered to be a "tech preview" version for that release. Committers adding new plug-ins to a DTP release should confirm the initial version with their project lead.

Back to the top