Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Its time to support fine-grained updates with meaningful version numbers


Another long, but important process note ... mostly about our 1.5 stream.

I'm sure everyone has taken my earlier advice a few months ago,
and studied up on some new proposed versioning conventions
which we in WTP will also follow. See

http://www.eclipse.org/equinox/documents/plugin-versioning.html

So ... now is the time to make our move. I moved the base builder earlier
this week, and did a test of one plugin (jsp.core) last night and all seemed
fine (much to my disbelief :) .. much thanks go to base platform/builder team
for making this change so easy for us to get started on -- mark my words, this will
be hailed as "the greatest advance in Eclipse since content types were introduced"  :)

So ... committers, now its our turn.

1. For everyone: for every plugin/feature you own, you need
to add ".qualifier" to the end (fourth field) of the version ID. yes,
literally, the 'dot' and the word "qualifier".  The new base builder and
PDE build add the map's cvs version in place of
that word. [I may fix up some of these for you, if it appears I can
do so easily and safely.]

2. For any plugins that you change (other than above
change I guess :)
increment the version number according to
the "amount of planned changes rules"
outlined in
http://www.eclipse.org/equinox/documents/plugin-versioning.html
Here's a simplified list of rules, since we are at "1.0.0" and just getting started.

        A. Do not change the version number (ever) if the code does not change.
                (well, not counting adding ".qualifier" ... we'll still need that).

        B. in WTP 1.5 dev. stream increment (change) the third place service field from '0' to '100' if just bug fixes
              [it's 100 so as to "leave room" for fixes on the 1.0.1 stream .. we better not need 99 bug fix releases :)

        C. increment by one the minor (second) place if substantial new
             additional function or API's made.

        D. increment by one the major (first ) place, if any API breaking changes are made.

That last one, D,  was just an attention test  :) ... no one should be making API breaking changes
in our WTP 1.5 release!  

The feature versions should be change according to its "most changed" contained plugin.

Note, the version number typically just changes once, maybe twice, for each major development cycle,
but it should be changed early, preferably when (and only when) first changed. (though, I know, its
already too late for that rule, for most of us :(

The above comments mostly apply to our WTP 1.5 stream ... it is still a possibility we'll want to do something
similar on our 1.0.1 stream, but I'm not sure yet (anyone have an opinion about 101?).  Note, its kind of interesting
that while we will still (probably) call our mid-year release "WTP 1.5", this will now be called a "marketing version" ...
no plugin should actually have that version number.  I suspect most will end up as 1.1.0.v20060523_0015, or similar,
but there might be a few unchanged, or bug fix-only plugins.

The issue of what versions tor require as pre-reqs will be (I think) a little harder to decide, and we will address in the month ahead (and,
after that maybe jar signing?)

I'm sure there will be many questions as we move forward, so don't hesitate to ask,
or suggest improvements or corrections to my description above.


Back to the top