On Oct 4, 2012, at 1:05 PM, Brian Watt wrote: > Prior to a release, the API baseline should always be the previous
> release version (5.0.0, 6.0.0, etc.) Once a release has occurred,
> the baseline should be changed to that release. Baselines are always
> the initial release version, not service release versions.
> This would be (b) in your list.
OK, the rule I now have is to use the last major release PTP master zip, which is currently 6.0.0, and to only move up when a major release happens. Should this include SRs?
A SR can never have any API changes, so you can stick with the major release version. API changes are only allowed in major/minor releases as these require a release review, which is normally taken care of as part of the Juno/Kepler/etc. release cycle. A major or minor version increment on a plugin will require a new PTP release. So if we need to bring out a 6.1 version of PTP, then we'll need to do a release review.
> The API tooling will indicate an error if you need to change the
> manifest version and/or add @since. It should provide you with a
> quick fix that will have the version you should use.
The next rule is that if I'm adding significant new APIs to some plugin that I update the bundle version to the next version. For example, org.eclipse.ptp.etfw bundle version was at 5.0.0 in the PTP master zip of 6.0.0, so I should bump it from 5.0.0 to 6.0.0. However, once it is updated there is no need to update the bundle version further until the next major PTP release. What should be done for an SR, for example, go from 6.0.0 to 6.1.0?
You should use quick fix for the manifest version since this will upgrade the major/minor version automatically for you. Normally API breakage will require a major increment and API changes will required a minor increment.
Then my final rule is that when I add in a new API that I should include an @since of the plugins bundle version. For example @since 6.0 for an API that is added to the org.eclipse.ptp.etfw with bundle version 6.0.0. What should be done for an SR, for example, use @@since 6.1?
The API tooling will tell you if an @since is required. The @since version will also be set automatically by the quick fix, but should be the same version as the manifest. For this reason, it is a good idea to fix the manifest version first (see above), then fix the @since versions. Otherwise you may have to go back and do them again.
A couple of other things. A major version increment on a plugin does not necessarily require a major release. We would probably still only do a minor (e.g. 6.1) release, unless there was significant changes to functionality also. For PTP, the release version is reflected by the feature versions. Plugin versions are independent of feature versions, so it is possible to have (e.g.) a 6.1 feature version and a 7.0 plugin version.
Hope this clarifies the situation.
Greg
|
