Community
Participate
Working Groups
4.2-I20111018-2000. It looks like the Platform Doc ('org.eclipse.platform.doc.user/isv') is not taken from 'master' but from a separate branch. All components (except UI) add new doc in 'master'. All those updates are currently not present in 4.2. Take bug 357335 as an example. Either 4.2 must go back to 'master' or make sure all 'master' changes are consumed by the separate 4.2 branch.
We should be consistent with UI, and have master be R4 development, and have a separate R3_development branch for 3.x doc. We should focus on the R4 documentation, and if some changes don't get backported to 3.x it's not as big of a problem.
It also looks like the current 4.2 doc in R4_HEAD has changes but they were never submitted to a build. I've not done this together with adopting the new ICU bundle that has been added a while ago. It looks like the Releng tests are not running against 4.x which could have reported the Javadoc problem. Mmh. Also, just for the bookkeeping: I've added the missing 'R4_1_1' tag and also created a R4_1_maintenance branch.
> I've not done this together with adopting the new ICU bundle that has been > added a while ago. Just in case: this is going to be pushed in a few minutes...
Aggregate move to M5. Retarget to a different milestone if you wish...
I've merged in the contents of master (3.8) into R4_HEAD, including the other doc bundles. We have to confirm the shape of the 4.2 doc and make sure we can manage changes from 3.8 to 4.2. This will help when doing the 4.2 primary build. PW
John, we'll have to tag this for the next 4.2 build, tomorrow PW
There's a deeper problem that the 4.2 build doesn't even contain the 4.x stream doc bundles. 4.2 M5 contains org.eclipse.platform.doc.[isv|user] from 3.8 M5. It looks like this is ok in the 4.2 "full build" though.
In case we do any more short builds, I have updated the maps (they were still pointing to CVS): http://git.eclipse.org/c/e4/org.eclipse.e4.releng.git/commit/?id=2750fad612dfb7fa3d534c46de9c2a58cdbbd9ef
(In reply to comment #1) > We should be consistent with UI, and have master be R4 development, and have a > separate R3_development branch for 3.x doc. We should focus on the R4 > documentation, and if some changes don't get backported to 3.x it's not as big > of a problem. I disagree. Even after 3.8, JDT will have to make its Java 8 support work in 3.x and 4.x. We don't want to be forced to do every doc change twice. Maybe we could split off a common.3x repo. This would be easier than tweaking the builder to be able to build from different branches.
I'll repeat my comment from bug 376182 comment 6 but add to it since I feel stronger about it now ... if I may venture a fresh view from a new comer ... I don't know why you wouldn't have a pde.doc and jdt.doc repo and let them follow pde and jdt. Seems to me you want things in its own repo if you think they might branch together (or not) and I don't see PDE and JDT that tightly bound. After all ... at one point you thought "platform, jdt, and pde" would all be branched together and that's turned out wrong :) Plus, I'd find "3.x" in any name confusing if it was really intended for both 3.x and 4.x. MHO
(In reply to comment #10) > I'll repeat my comment from bug 376182 comment 6 but add to it since I feel > stronger about it now ... if I may venture a fresh view from a new comer ... I > don't know why you wouldn't have a pde.doc and jdt.doc repo and let them follow > pde and jdt. Seems to me you want things in its own repo if you think they > might branch together (or not) and I don't see PDE and JDT that tightly bound. > After all ... at one point you thought "platform, jdt, and pde" would all be > branched together and that's turned out wrong :) > > > Plus, I'd find "3.x" in any name confusing if it was really intended for both > 3.x and 4.x. > > MHO Both valid points. Another approach could be a commit hook that automatically cherry-picks JDT and PDE pushes to 'R4_HEAD'.
Paul, you marked this 4.2.1. Do you mean the general process, or do you intend to ship outdated doc for 4.2?
(In reply to comment #12) > Paul, you marked this 4.2.1. Do you mean the general process, or do you intend > to ship outdated doc for 4.2? They mean the general process. John and I will make sure that master and R4_HEAD match for Juno/3.8, probably by merging. PW
(In reply to comment #13) > (In reply to comment #12) > > Paul, you marked this 4.2.1. Do you mean the general process, or do you intend > > to ship outdated doc for 4.2? > > They mean the general process. John and I will make sure that master and > R4_HEAD match for Juno/3.8, probably by merging. > > PW Filed bug 379204 to track that.
The title needs updating because master will now be for 4.3 development. There may be some value in synchronizing doc updates between 3.8.1 and 4.2.1 maintenance streams.
(In reply to comment #15) > The title needs updating because master will now be for 4.3 development. There > may be some value in synchronizing doc updates between 3.8.1 and 4.2.1 > maintenance streams. I think we will not have that many doc changes to justify working on this bug. Suggest to close as INVALID.
Closing.
