Community
Participate
Working Groups
Created attachment 228776 [details] patch.eclipse.platform.text.R3_8_maintenance To be applied right after I20130326-0800
Created attachment 228800 [details] patch.eclipse.platform.text.master
Paul, the patch hammers "4.2.2" as parent version into the 3.8 maintenance branch. What happens if a 3.8.2+ build is needed? Does this still work? If so, why not use 3.8.2 instead in the first place? Or, are 3.8.2+ and 4.2.2+ both using the same parent version (4.2.2)? Would be ugly though. On the other hand, I see that so far, we used "3.8.0" for both 3.x and 4.x (not nice either ;-).
(In reply to comment #2) > Paul, the patch hammers "4.2.2" as parent version into the 3.8 maintenance > branch. What happens if a 3.8.2+ build is needed? Does this still work? If > so, why not use 3.8.2 instead in the first place? Or, are 3.8.2+ and 4.2.2+ > both using the same parent version (4.2.2)? Would be ugly though. On the > other hand, I see that so far, we used "3.8.0" for both 3.x and 4.x (not > nice either ;-). Right :-) It was deliberately done that way, because we'll initially be providing 4.2.2+ and you have to match the parent. But I made sure that you could do a 3.8.2+ as well, while still using the 4.2.2-SNAPSHOT parent without changing the parent pom itself (it's supplying one -D property to the build). So given that we can support 3.8.2+ if we need to and that these parent pom build artifacts don't show up anywhere in our build p2 repo I think it's OK to make the consistent with 4.2.2+ PW
(In reply to comment #3) > (In reply to comment #2) > > Paul, the patch hammers "4.2.2" as parent version into the 3.8 maintenance > > branch. What happens if a 3.8.2+ build is needed? Does this still work? If > > so, why not use 3.8.2 instead in the first place? Or, are 3.8.2+ and 4.2.2+ > > both using the same parent version (4.2.2)? Would be ugly though. On the > > other hand, I see that so far, we used "3.8.0" for both 3.x and 4.x (not > > nice either ;-). > > Right :-) It was deliberately done that way, because we'll initially be > providing 4.2.2+ and you have to match the parent. But I made sure that you > could do a 3.8.2+ as well, while still using the 4.2.2-SNAPSHOT parent > without changing the parent pom itself (it's supplying one -D property to > the build). > > So given that we can support 3.8.2+ if we need to and that these parent pom > build artifacts don't show up anywhere in our build p2 repo I think it's OK > to make the consistent with 4.2.2+ > > PW Understood. Is the reason that it also works for 3.8.2+, because all will have 4.2.2 in it? Or in other words: do all parent versions have to be identical for a certain build, or could we just use "3.8.2" and this would then also work for the 4.2.2+ build? I ask, because for those who did not split and still have 3.x bundle versions, it would be more consistent to go with 3.8.2.
(In reply to comment #4) > Understood. Is the reason that it also works for 3.8.2+, because all will > have 4.2.2 in it? Or in other words: do all parent versions have to be > identical for a certain build, or could we just use "3.8.2" and this would > then also work for the 4.2.2+ build? I ask, because for those who did not > split and still have 3.x bundle versions, it would be more consistent to go > with 3.8.2. You're right, we could do it the other way. Make the 3.8.2-SNAPSHOT the main parent for 3.8.2+ and use it in 4.2.2+ (so all parents would read 3.8.2-SNAPSHOT) and pass the property in that build. I had targetted it the other way because 4.2.2+ is our primary delivery to LTS and the release train, but there's no technical reason it couldn't be done the other way. Just all the patches would need to be regenerated. PW
(In reply to comment #5) > You're right, we could do it the other way. Make the 3.8.2-SNAPSHOT the > main parent for 3.8.2+ and use it in 4.2.2+ (so all parents would read > 3.8.2-SNAPSHOT) and pass the property in that build. If one can fake 3.8.2 to look like 4.2.2, can't we fake anything i.e. can't we just forget about that parent version? After all the branch defines the stream. > I had targetted it the other way because 4.2.2+ is our primary delivery to > LTS and the release train, but there's no technical reason it couldn't be > done the other way. Just all the patches would need to be regenerated. Wouldn't it be enough if only those components/teams adjust their patches, who care about the version to be 3.8.2 in the 3.8.2+ branch?
(In reply to comment #6) > > If one can fake 3.8.2 to look like 4.2.2, can't we fake anything i.e. can't > we just forget about that parent version? After all the branch defines the > stream. We can't forget about the parent version entirely, our parent pom has to point to something. In theory if you parameterize everything with properties you could have one parent for your project and call it with properties specific to the branch you want. That means unless you're building on master this week, you'd have to pass in parameters for all of the repo URLs, compiler co-ordinates and versions, tycho versions, and a host of other configurations. That's not really making the build easier. > Wouldn't it be enough if only those components/teams adjust their patches, > who care about the version to be 3.8.2 in the 3.8.2+ branch? No, because they need a parent to point at, so eclipse-platform-parent has to have to be changed and then all of the poms that point to it. Or are you talking explicitly about eclipse.jdt.ui:eclipse.jdt.ui which is already confined within your repo in the correct branch? I set it up the way I did because 4.2.2+ is the primary build and part of LTS, but there's nothing to stop a repo from changing its POMs that act as parents with its own versioning scheme (although just like re-exporting API, if your parent changes your own version has to change). PW
(In reply to comment #7) > Or are you talking explicitly about eclipse.jdt.ui:eclipse.jdt.ui which is > already confined within your repo in the correct branch? I set it up the > way I did because 4.2.2+ is the primary build and part of LTS, but there's > nothing to stop a repo from changing its POMs that act as parents with its > own versioning scheme (although just like re-exporting API, if your parent > changes your own version has to change). Yes, I was referring to a single repo, e.g. JDT, who provides its 3.8.x bits to both, 3.8.2+ and 4.2.2+. I assume, I can only replace "4.2.2" with "3.8.2" in the JDT patches then. Or is there something else to do?
(In reply to comment #8) > > Yes, I was referring to a single repo, e.g. JDT, who provides its 3.8.x bits > to both, 3.8.2+ and 4.2.2+. I assume, I can only replace "4.2.2" with > "3.8.2" in the JDT patches then. Or is there something else to do? You would have to leave the eclipse-platform-parent reference as 4.2.2 as that is set outside your repo. But all of the other 4.2.2 references you could set to 3.8.2 and it would still work. In this bug, for example, you would leave this part alone: <parent> <groupId>org.eclipse</groupId> <artifactId>eclipse-platform-parent</artifactId> - <version>1.0.0-SNAPSHOT</version> + <version>4.2.2-SNAPSHOT</version> <relativePath>../eclipse-platform-parent</relativePath> </parent> But all of the other references to 4.2.2 refer to eclipse.platform.text:eclipse.platform.text and you could set them all to 3.8.2 PW
Fixed in 'master' with http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=f8c10c8bd860e32193fe576f0bcb59ba2a238db9 - excluded addition of forceQualifierUpdate.txt
Fixed in 'R3_8_maintenance' with http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=88b38e53715451922cb9f051ee98ff48a82d6cbc - excluded addition of forceQualifierUpdate.txt Since we can't get rid of "4.2.2" entirely, we decided, it's better to keep the wrong version in order to be consistent with all other bundles.
