Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #409686 +++ Thought this issue deserved its own bug, since effects "whole team" and may need some discussion. In fact we eventually need to make two changes, and have two branches. The first need is that in "master", we should change to parent pom version to "4.4.0-SNAPSHOT" instead of its current "4.3.0-SNAPSHOT". (But, see bug 409686 comment 16 and related comments for alternatives ... if anyone can see and explain advantages/pros/cons). And once we change it in the actual parent pom, everyone who names it as their parent needs to update ... there's about 25 or 30 other pom's that need updating. And then ... the hard part ... when we create a R4_3_maintenance branch, we have to "do it all again", and use 4.3.1-SNAPSHOT. At least, that'd be the "most correct" thing to do. The definition of the parent POM will likely not change much for 4.3.1, but it will change some. Some of our pre-reqs URLS will likely change, we may end up using Tycho 0.19 or at least version 1.0.4 of "CBI Plugins". And, as before everyone needs to have a "matching" parent. Which means that everyone has to have an R4_3_maintenance branch "at the same time" ... even if all changes being made are identical changes for both "master" and "R4_3_maintenance" ... so that implies lots of cherry picking for some teams? Should we put off having an R4_3_maintenance branch for a long as possible? (Which would be sometime in August). This might help if some teams had a lot of maintenance changes to do in June/July then they'd have to just make in master, and at some time in August create their separate branches from their current point in master. Or should we do it soon, with the idea its easier to "keep up in sync" if it becomes a normal work flow, rather than something that starts in August?
I will give a concrete proposal for the 4.4.0-SNAPSHOT change ... I suggest we plan on doing that on 6/26, the official day of "Simultaneous Release". That will be on a "Wednesday", so ... just in case ... will give some time for a few N-builds to fail, if people forget some pom's, before next I-build on following Tuesday. Note: there are already some bugs waiting to change "parent pom" (e.g. bug 406157).
Forcing unchanged bundles / repos to change in the maintenance stream, just because of the POM version, is a no go and severe design flaw if there is no other solution. I would expect that the 4.3m/4.4 builder can simply have a rule to convert a 4.3 version to 4.3.1/4.4.
(In reply to comment #2) > Forcing unchanged bundles / repos to change in the maintenance stream, just > because of the POM version, is a no go and severe design flaw if there is no > other solution. I agree that I find the maven way to scale horribly. But this is the maven process (that we're now following). The half-and-half alternative: 1) we go ahead with the 4.4.0-SNAPSHOT change in Luna and push our 4.4.0 parent pom to repo.eclipse.org 2) we leave R4_3_maintenance to use 4.3.0-SNAPSHOT for all of the following releases (SR1, SR2, and 4.3.2+). We used 4.2.2-SNAPSHOT in R4_2_maintenance because we were moving up from 1.0.0-SNAPSHOT (totally meaningless) to version of the parent pom tied to the branch (and we were at 4.2.2 when we did it). While using 4.3.1-SNAPSHOT and 4.3.2-SNAPSHOT is very clear, because we never graduate those snapshots to releases they will always continue to change anyway. Since it's already clear what branch 4.3.0-SNAPSHOT applies to, we leave it alone. PW
(In reply to comment #0) > And then ... the hard part ... when we create a R4_3_maintenance branch, we > have to "do it all again", and use 4.3.1-SNAPSHOT. At least, that'd be the > "most correct" thing to do. The definition of the parent POM will likely not > change much for 4.3.1, but it will change some. Some of our pre-reqs URLS > will likely change, we may end up using Tycho 0.19 or at least version 1.0.4 > of "CBI Plugins". > > And, as before everyone needs to have a "matching" parent. Which means that > everyone has to have an R4_3_maintenance branch "at the same time" ... even > if all changes being made are identical changes for both "master" and > "R4_3_maintenance" ... so that implies lots of cherry picking for some > teams? I can't speak for the other teams, but our standard process is to release fixes into master (so they garner the widest audience for testing) and then port them back to the maintenance stream. I know last year Platform UI focused on the maintenance stream for a lot longer than normal, but this year we'll be following the standard process. I think it's OK to branch from R4_3 after we've tagged the official release. PW
(In reply to comment #4) > (In reply to comment #0) > > And then ... the hard part ... when we create a R4_3_maintenance branch, we > > have to "do it all again", and use 4.3.1-SNAPSHOT. At least, that'd be the > > "most correct" thing to do. The definition of the parent POM will likely not > > change much for 4.3.1, but it will change some. Some of our pre-reqs URLS > > will likely change, we may end up using Tycho 0.19 or at least version 1.0.4 > > of "CBI Plugins". > > > > And, as before everyone needs to have a "matching" parent. Which means that > > everyone has to have an R4_3_maintenance branch "at the same time" ... even > > if all changes being made are identical changes for both "master" and > > "R4_3_maintenance" ... so that implies lots of cherry picking for some > > teams? > > I can't speak for the other teams, but our standard process is to release > fixes into master (so they garner the widest audience for testing) and then > port them back to the maintenance stream. So it is!
(In reply to comment #2) > Forcing unchanged bundles / repos to change in the maintenance stream, just > because of the POM version, is a no go and severe design flaw if there is no > other solution. > > I would expect that the 4.3m/4.4 builder can simply have a rule to convert a > 4.3 version to 4.3.1/4.4. Just to give a reminder, even if a particular bundle or repository does not change code, due to the hierarchical inheritance of POMs, they do potentially change, even if the code doesn't ... such as if third party pre-reqs change, or compiler options change, etc. As another reminder, we are partially in this situation because we have a monolithic build. I think most that use maven/Tycho basically build "a feature at a time", or "one repository at a time". Even then, though, in our case, that would mean having lots of of different parent POMs (e.g. 10 to 15) , which to some degree would all have to stay in sync, though maybe not quite so strictly or literally as our current design (e.g. if Orbit pre-reqs changed in one, it should change in all). From a quick read of http://blog.xebia.com/2012/09/30/continuous-releasing-of-maven-artifacts/ it does appear possible to "pass in" a variable value for version/revision, but that sort of spoils the simple 'mvn clean verify' invocation of our build ... people would have to know exactly what values to use. And, I think its more for "pure maven" case where all artifacts are maven artifacts, which is not our case. But, I am sympathetic ... it seems odd. And I guess we are "lucky" that "POM only" change is not used in the computation of qualifier ... so, a bundle's qualifier should not change just because its parent POM version changed.
(In reply to comment #3) I'm fine with the "half and half" approach. It certainly fits our specific needs within our own builds ... But, it's not clear to me if or how others make use of our "eclipse-platform-parent". But am fine waiting for "complaints" or use-cases that dictate some other arrangement. (Though, by that same logic, we wouldn't have to change at all :) (In reply to comment #4) And by "I think it's OK to branch from R4_3 after we've tagged the official release." ... you mean everyone HAS to branch ... and then we could startup M-builds at any time, right? [Our SR1 RC1 +0 day is 8/16 ... so we'd have to start mid-July in any case ... not that far away!].
(In reply to comment #7) > And by "I think it's OK to branch from R4_3 after we've tagged the official > release." ... you mean everyone HAS to branch ... and then we could startup > M-builds at any time, right? [Our SR1 RC1 +0 day is 8/16 ... so we'd have to > start mid-July in any case ... not that far away!]. We could talk about it at tomorrows arch call. While I'd prefer that all the repos branch (it makes so many things in git sooo much easier) that wouldn't be a requirement for starting the M builds, since we could fill in the repositories.txt file with the R4_3 tag. PW
So, we can build 4.3.1 with 4.3.0 and we've built 4.3 with 3.9.0 as parent at some point. Plus, the branch/tag comes from our repositories.txt file. This indicates to me, that this parent pom is not that important. Couldn't we just leave it 4.3.0 everywhere? Wouldn't that just work?
No, it won't work. The differentiator is multiple branches built at the same time. We can leave 4.3.0-SNAPSHOT in place while people build 4.3.1 and then 4.3.2 (as they're not parallel builds). But we need to upversion Luna to 4.4.0-SNAPSHOT because 4.3.x and 4.4.x will be built at the same time, and they contain different configurations (different p2 repos, different tycho levels, different maven plugins, different JDT compilers, etc) PW
(In reply to comment #10) > No, it won't work. The differentiator is multiple branches built at the > same time. > > We can leave 4.3.0-SNAPSHOT in place while people build 4.3.1 and then 4.3.2 > (as they're not parallel builds). > > But we need to upversion Luna to 4.4.0-SNAPSHOT because 4.3.x and 4.4.x will > be built at the same time, and they contain different configurations > (different p2 repos, different tycho levels, different maven plugins, > different JDT compilers, etc) > > PW I see. In the architecture call, we decided that we will not change the parent version in the 4.3 maintenance branch, but change it for Luna. Paul offered to provide patches. We all agreed that Maven should be more flexible/scalable with respect to the parent version. Paul or David, can you bring that forward to Maven / raise a bug there? Thanks!
(In reply to comment #11) > (In reply to comment #10) > > ... We all agreed that Maven should be more > flexible/scalable with respect to the parent version. Paul or David, can you > bring that forward to Maven / raise a bug there? Thanks! I don't recall us agreeing to that. From my memory, the statement was in theory it could be done, by generating things "on the fly", from some "pre-build" scripts, but that this was "counter to Maven culture" and then each person who wanted to build our stuff "locally" would need more intimate knowledge of our custom pre-build scripts, instead of being able to just check out the parent and do 'mvn clean verify'. To me, the situation is exactly analogous to pre-req version ranges in bundles. Some projects ... for years, and even currently ... compute those ranges "on the fly" at build time, based on some custom procedures/scripts they use during their build. But, then, you can not tell, from checking out what's in Git what the committer intended. Its some "extra" knowledge embedded in build scripts. I think the Eclipse Project (and others) have decided that "its part of our culture" for the committer to decide and state what the right range is, and check that into the repository, so that anyone checking out the code knows what the appropriate ranges are. We would not have to do it that way ... but ... we do because we consider it the best practice. So, just like we could change our minds about how to compute pre-req ranges, we could change our minds about how to compute parent requirements -- and tie it all together with custom build tools. That's my memory of the discussion ... but I would be the first to admit, maybe that discussion was "all in my own head". :) Corrections welcome.
Assuming all is well, since we are building! :) Thanks everyone for your careful attention and coordination.
