Community
Participate
Working Groups
clipse-SDK-I20130219-1600-win32-pde has: org.eclipse.swt_3.101.0.v4320 eclipse-SDK-I20130225-2315-win32-cbi has: org.eclipse.swt_3.101.0.v20130225-2226 It looks like the builder does not use the tags from the map file(s).
It should be ok for the swt repos to be auto tagged by the cbi builder and for the qualifier be a timestamp (instead of vXXXX) as long as we start building from our "integration" branch instead of "master" (bug#401813), since we can guarantee that the contents of the eclipse.platform.swt and eclipse.platform.swt.binaries are coordinated in the "integration" branch. I am not sure how to solve the version number decrease. Should we increment the minor version to 3.101.1? Do you have to solve this?
Outside of Kepler it won't matter because the minor or service segments of the version will be different. Within Kepler, it won't matter because the newer version hasn't been released, and is not considered during upgrades of the product (like the SDK or platform). So even with the change, going from SDK M5 to M6 will include the correct version of SWT (p2 only considers the root IU during an upgrade) It would probably be worth announcing the change in cross-projects PW
A primary directive is that version numbers never decrease (even if it might not be a problem in the end). Therefore the minor version must be increased. Note that the example in comment 2 is wrong it increments the service segment. Correct is: 3.102.0.qualifier.
(In reply to comment #3) > A primary directive is that version numbers never decrease (even if it might > not be a problem in the end). Therefore the minor version must be increased. > Note that the example in comment 2 is wrong it increments the service > segment. Correct is: 3.102.0.qualifier. That must be true from release to release. It should generally be true within a release, but it comes from the update manager time where an upgrade was in effect dumping all of the plugins in the the plugins folder and letting the resolver pick the highest one ... but we haven't done it that way in years. But if SWT wants to update the minor segment, that would fix it was well. PW
(In reply to comment #3) I don't think incrementing the service segment would be wrong. 3.101.1 would just not observe http://wiki.eclipse.org/index.php/Version_Numbering#When_to_change_the_service_segment 's "As a result, the service segment number for official releases normally ends with a zero", but this is isn't a "normal" case, after all. But 3.102.0 is also fine.
moving to SWT since its in SWT code.
OK, we will increment the 101 version. In the past we always tried to tie our version numbers to the release versions. Would anyone feel strongly about us incrementing our version from 101 to 143?
(In reply to comment #7) > OK, we will increment the 101 version. In the past we always tried to tie > our version numbers to the release versions. Would anyone feel strongly > about us incrementing our version from 101 to 143? http://wiki.eclipse.org/Version_Numbering has ;-).
As long as http://wiki.eclipse.org/Version_Numbering doesn't speak up, 3.143.0 is also fine ;-) The guidelines are defining the default procedures. If you have good reasons to deviate from the defaults and you can state these reasons, then that's OK as long as the deviation doesn't cause problems. The main problem is that the SWT plug-in was split at all (bug 377994), but we can't change that now. Note that the "3.1xy" scheme with "xy" defined by Eclipse Platform version "x.y" will only work for 6 more years, so you will soon be at 3.150, which is not better than just continuing with 3.102 etc. SWT.getVersion() will have the same overflow problem (currently at 43nn). Anyway, my feelings for or against 3.143.0 are not that strong. If I had to decide, I would just go with 3.102.0 and acknowledge that the bundle version numbers are not necessarily in sync with the platform version number (however you define "platform").
Going with 3.202.0 Fixed http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=4de3fbda087a82ce139bb3c3c3c0422b6dc3d1b8 http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=3eae804ff41a01362d1888687ba12efb502889d1
(In reply to comment #10) > Going with 3.202.0 I guess you meant 3.102.0 (at least that's what you took).
(In reply to comment #11) > (In reply to comment #10) > > Going with 3.202.0 > > I guess you meant 3.102.0 (at least that's what you took). Yeap :-)
