I agree with your initial intepretation,
that given the magnitude of changes we made between 3.5 and 3.6 we should
have incremented the minor segment of most or all p2 bundles. Clearly there
was signficant new feature work, and the current numbers suggest we only
made non-visible bug fixes. The API tools don't help us here because these
bundles don't have any API, and I think we have come to rely on the tools
to help us increment version numbers. We know there are adopters out there
consuming our provisional API, so I think we need to increment the minor
number when our provisional API changes, so clients can set their ranges
accordingly. So, here is my suggestion:
Increment minor segment for:
- Changes to provisional API
(breaking or not)
- Non-trivial visible changes
in the UI
- Additions or changes of command
line arguments to command line tools
- Other major code changes
Susan Franklin McCourt
<susan_franklin@xxxxxxxxxx> Sent by: p2-dev-bounces@xxxxxxxxxxx
06/29/2009 05:42 PM
Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>
[p2-dev] bundle version numbers...?
Per Dani's note to eclipse-dev last week , I realized
that I have updated some p2 code and did not update the bundle version
as part of making the changes.
I checked the version guidelines and in my case decided it was appropriate
to update the minor segment, because I made an externally visible change
(changed the way the license page works in the install wizards).
I then noticed that we shipped 3.5 with many (all?) p2 bundle version numbers
This would indicate no major changes since 3.4. I suppose since we don't
have any supported API, we could argue that none of the changes in 3.5
are externally visible.
At any rate...
Going into 3.6, what should we use as the bundle version number? If/when
we declare API, I would suppose we would move to 1.1.0.
But in the meantime, should we be using 1.0.200.qualifier?