Community
Participate
Working Groups
4.2 M2. The bundle version of 'org.eclipse.ui' is "3.7.100.qualifier" in 4.2 like it is in the 3.8 stream. However, from looking at the code and the actual 4.2 build it looks like we don't bundle the 3.8 version into 4.2. Hence the version should probably be changed.
I guess 3.100.0 would be a good choice, unless there are breaking API changes in which case we could use 4.0.0.
We haven't forked this bundle, it's one of the 'common' bundles shared by both 3.x and 4.x so there's no way to change the bundle version (nor should there be since there are also no 4.x specific code changes).
There are still some API issues when comparing the 3.x org.eclipse.ui.workbench with the 4.x one and since org.eclipse.ui re-exports packages we probably shouldn't close this bug yet. See bug 340088 comment 1.
(In reply to comment #2) > We haven't forked this bundle, it's one of the 'common' bundles shared by both > 3.x and 4.x I disagree for two reasons: 1. The bundle in the 4.2 download is not the one from the 3.8 download 2. The repository contains several changes in R4_development branch.
We wanted to update o.e.ui to 3.100.0 in 4.1, but we got to it too late in the game to change the minor number, so we settled for 3.7.100. I think going to 3.100.0 or some higher appropriate number to match o.e.ui.workbench would be fine in 4.2 PW
This is scary...this bundle has *not* been 'forked' so it should (*must*) be the same in both branches. In short, *all* projects except org.eclipse.ui.workbench and platform.ui have gotta be == between the two; otherwise we'll be missing fixes in things like JFace and Databinding depending on whether you're on 3.8 or 4.2. I thought that there was an 'auto merge' step in the builds to cherry pick from R4 into the R3 branch but perhaps it's not working ?
This cherry picking thing ain't workin'... After talking with John it seems that the R3/R4 branch setup was supposed to be an interim stage with us eventually using 'master' for most work. Paul, what was the intention My suggestion would be to start on this path now: 1) A compare of *all* of the 'common' projects to get them all == again and ensure that the result has been pushed to 'master'. Note that this is a pain but now needs to be done to detect other projects that have diverged. 2) *delete* these from both the R3 & R4 branches, leaving only the two forked projects. 3) make a new 'common' branch from master that contains the common bundles but not the forked ones In this world all development workspaces would include the 'common' branch and (if necessary) one of R3 or R4. More importantly it prevents the common projects from diverging by having them on only one development branch.
(In reply to comment #6) > This is scary...this bundle has *not* been 'forked' so it should (*must*) be > the same in both branches. org.eclipse.ui was forked almost a year ago. Paul delivered to the R4_HEAD branch for bug 319553 anyway. http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.ui/schema/actionSets.exsd?view=log&pathrev=R4_HEAD > I thought that there was an 'auto merge' step in the builds to cherry pick from > R4 into the R3 branch but perhaps it's not working ? (In reply to comment #7) > This cherry picking thing ain't workin'... I'm not sure if anyone ever went to Andrew with their commit to test this script that he wrote. Assuming no one ever did, then he would not have had put it up on the build server.
(In reply to comment #8) > org.eclipse.ui was forked almost a year ago. Yes, org.eclipse.ui was forked, originally because of the build notes update (which was a procedural convenience) and then when I deprecated all of the action extension points (4.x only, not 3.x) As for the branches: What we actually should have: master (currently R4_development): All work for 4.x (4.2). R3_development: Any commits from master that are appropriate for 3.8, plus any fixes to o.e.ui.workbench for 3.8. R3_7_maintenance: 3.7.1 and now 3.7.2 work. We have something more wonky set up because the builder could only build nightlies from master *and* we build 3.8 and then 4.2. Andrew has fixed the builder, so that the 3.8 nightlies can be built from R3_development. That means we could update the 3.8/nightly builds, put master back to the 4.x development, and remove the R4_development branch. Eventually, Kim will get the 4.2 build running first, and build 3.8 from appropriate 3.8 branches + the 4.2 build output. That still leaves us with maintaining the 2 branches, master (4.2) and R3_development (3.8). It's the same as working in July in 3.7.1 ... the developer has to make sure that a fix in 3.7.1 is propagated into 3.8 (in our case, a developer has to make sure a neutral code change goes into master and R3_development). If we can use Andrew's cherry-pick scripts on anything that doesn't touch o.e.ui.workbench, that's great. If not, we'll need to make the changes ourselves. However, in this case, o.e.ui *was* forked, and ended up as 3.7.100 because we needed to increase the number but because it was late it was deemed too risky to simply switch to 3.101.0 in the Indigo end game. PW
> However, in this case, o.e.ui *was* forked, Right, and one not only sees this in the code/branch but also because 4.2 does not pick the 3.8 bundle but builds its own version. > and ended up as 3.7.100 because we > needed to increase the number but because it was late it was deemed too risky > to simply switch to 3.101.0 in the Indigo end game. I've fixed the bundle version in 'R4_development' to "3.102.0.qualifier". I won't touch 'master' until we officially switch to the new (and correct) model where we use 'master' for 4.2 and retire the 'R4_development' branch. Commit c49ba5f8d40b9373cf74e716a93c5a236589577b.
Another option if the branching is proving too painful, is to keep everything in master and have a setup like this: bundles/ org.eclipse.ui.workbench .... tests/ bundles3x/ org.eclipse.ui.workbench The only disadvantage is you wouldn't be able to pick a commit from the main ui.workbench and cherry-pick it over to the 3x workbench because it would be in the same branch. I don't know how common this is, but it may be worth the inconvenience if it makes development on the rest of the bundles simpler.
I have opened bug 359616 to discuss reorganizing the streams for Platform UI development.
