Re: [dtp-dev] Plugin and Feature Versioning

[rcernich@xxxxxxxxxx]

Hey Sheila,

> I'll throw my opinion out for starters... I strongly feel we need to
abide by
> the versioning criteria as described in the Eclipse versioning
documentation.
> Some of our adopters are sensitve to version numbers and we can prevent
them
> from being able to upgrade if we increment versions outside their
specified
> tolerance ranges.
>

This works for me.  However, I think some details require further
clarification in the context of DTP.

For example, DTP is scheduled to release a "1.5" version for Europa.
Because of this, I recommend that any plug-ins affected by non-breaking API
changes or significant work (including new features and API) should be
rolled out as "1.5" as opposed to "1.1".  I also think this should be a one
time exception.  With respect to changes which break existing API, I don't
think we should be making these.  For me at least, defining the next DTP
release as "1.5" implies that no API will be broken.

In the future, I think the DTP feature releases (and project version)
should be governed by the changes made/planned for each of the individual
plug-ins.  I also think this needs to be accommodated early in the release
planning.  If breaking API changes are planned, the next DTP version, would
be "2.0" (note, individual features within DTP would be versioned based on
their individual plug-ins; meaning not all DTP features would be "2.0").
If no breaking API changes are planned, the next DTP version should be
"1.6".

To summarize, I agree with Sheila that:
1.  Plug-ins should be versioned using the above guidelines, with the
exception that the minor version should be changed to "1.5" for the current
release.
2.  Feature versions should be based on the highest version number of their
included features or plug-ins.
3.  The DTP project version should match the highest version number of any
of its features.
4.  The decision to allow API breaking changes into a release should be
made early on in the release cycle. (I would view this as giving projects
the authority to make breaking changes.)  I would view the proposed release
version as tentative, based on the assumption that breaking changes will be
made.  If no breaking changes are made, only the minor version number
should be increased.

(Note, included plug-ins includes any plug-ins reexported by DTP.  This is
noted in the document detailing plug-in versioning.)

Best regards,
Rob Cernich
DTP Connectivity Project Lead