Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #436736 +++ This is just a general bug to make notes of what I (we) need to do to build after current development cycle ... see original bug 436736 for an outline of what must be done. There is nothing to do right now ... but, I'm opening this now as a reminder for us all to pencil-in some time to take the necessary steps. I propose we begin this after Mars officially releases (Wed., June 24) with a goal of being operational ... say July 8?. (Or July 15, at latest). [I'm uncertain only because I am not sure of effects of holiday and vacations during that time ... not to mention "taking a break" after our release!]
(In reply to David Williams from comment #0) > I propose we begin this after Mars officially releases (Wed., June 24) with > a goal of being operational ... say July 8?. (Or July 15, at latest). +1
Created branches for these repos: - jdt/ - most of platform/ TODO: - platform/eclipse.platform.[resources|team] - pde - equinox Easiest way via committer shell: build.eclipse.org/*.git$ git branch R4_5_maintenance R4_5
Done for equinox (including p2).
I've made a bunch of changes to aggregator, to build "Neon 4.6" instead of "Mars 4.5" ... EXCEPT I have not yet changed parent pom. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=764f2d3d74fadd0ead4b648bf23987108522fb08 I'm going to try a test build with changes so far, and our N-build tonight will be with things "as is". And then I suggest on Thursday, I'll change the parent pom to "4.6", and at point, all the other repos that refer to that parent will also need to be updated before we can build again. Is that timing reasonable? Are there enough people around to update all repos? Let me know if there is a better day to plan the coordinated changes. Thanks,
(In reply to David Williams from comment #4) > Is that timing reasonable? Are there enough people around to update all > repos? > Let me know if there is a better day to plan the coordinated changes. > > Thanks, I can update Equinox repos on Thursday.
I've noticed the 0701 N-build still says "4.5.0 Nightly" and goes to "4.5 update site" ... I thought I fixed both of those things ... so ... I'll dig into it. Double check my work.
(In reply to David Williams from comment #6) > I've noticed the 0701 N-build still says "4.5.0 Nightly" and goes to "4.5 > update site" ... I thought I fixed both of those things ... so ... I'll dig > into it. Double check my work. I'd just forgotten to update the "control" files on the build machine, which is a manual step by design. So, I tried starting another N-build around midnight ... just to get a better view of what works and what doesn't.
(In reply to David Williams from comment #4) > Is that timing reasonable? Are there enough people around to update all > repos? Yes, sounds good. And if even if an N-build breaks, that's not really worse than having no build. I can do JDT and most of the platform. Components where we need other committers until Dani is back: - PDE (Vikas, Curtis, Mike) - Platform Workspace (Szymon)
(In reply to David Williams from comment #4) > Is that timing reasonable? Are there enough people around to update all > repos? > Let me know if there is a better day to plan the coordinated changes. > > Thanks, I am back from vacation and can update Platform/Workspace repos when needed.
I can update PDE
Created branches for these repos: - platform/eclipse.platform.[resources|team] For the records, those who don't have full shell access may still use steps from comment 2 if it's done in a single command, e.g.: git --git-dir=/gitroot/platform/eclipse.platform.team.git branch R4_5_maintenance R4_5 Kudos to Markus for the hint.
I have now changed the version of parent pom to "4.6.0-SNAPSHOT" (instead of 4.5.0-SNAPSHOT). http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=0304a6ba994bbfae927d819a663924aba0de3490 I'll update a few more pom's to match, and as a reminder to others (since I initially forgot) many of the pom's that need updating will not be visible from package explorer, and will need to be updated from "working tree" in the "git repository view". (depending on what and how you import things). I will try a few test builds through out the day ... in case we need some reminders of things to update. I probably won't get a chance to start thinking about "maintenance" until late in the day. I did notice in last N-build, another "TODO" for me, is to update the reference repo for performance test ... to use 4.5 release, instead of 4.4.
Another thing I'd forgotten, but when I updated repository pom for eclipse.platform.releng, realized that both the 'artifact' as well as the parent should be updated. <parent> <groupId>org.eclipse</groupId> <artifactId>eclipse-platform-parent</artifactId> <version>4.6.0-SNAPSHOT</version> <relativePath>../eclipse-platform-parent</relativePath> </parent> <groupId>eclipse.platform.releng</groupId> <artifactId>eclipse.platform.releng</artifactId> <version>4.6.0-SNAPSHOT</version> <packaging>pom</packaging> This in turn means other projects in that repo that refer to eclipse.platform.releng as the parent need to be updated to match. (right?) Guess maybe that's why we avoided changing anything for maintenance, unless we absolutely had to (for our needs) -- anyone have an opinion if we should update maintenance to "4.5.1" (and be good maven citizens) or leave as "4.5.0" when we can? (I do know we need to update some product projects, but do not think others need to be updated, for our build or deliverables).
I've done these four repositories. I did use care not to update the artifact ids for things like "eclipse sdk feature" (just the parent) -- even though, I'm sure we will soon ... just thought best to leave that as a separate concern. eclipse.platform.releng.aggregator eclipse.platform.releng eclipse.platform eclipse.platform.common
Update "previous release" properties. <== add to "outline of things to do". Besides the performance baseline, found a number of places that depend on "previous release". Some of these are for purposes of tests. Some of them are for simply running utilities, such as running "antRunner" application. Some of them need to be updated for any release (major, minor, or service) some need to be updated only for major releases. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=27247a37049196afca0d5a84f2d986f564405f9f = = = = = = = = = = Another item to add to outline of "things to do" (though, changed with one of first commits). To document it, we specify a repo for building "individual bundles" -- eclipse-p2-repo.url property, in parent pom. During normal development period, we use N-build repo (since it's "current" nearly every day), but during RC cycles, that was changed to I-build repo, since there were no N-builds, and since I-builds were everyday anyway. So, now that we've released, I not only changed to "4.6", but also changed back to N-builds repo.
On the topic of changing maintenance "parents" to be 4.5.1, I suggest we hold off on that, and treat it separately. I have opened another bug to discuss and decide that issue: bug 471732 - Should we update non-delivered artifacts to reflect service version? That will make it easier to get the maintenance builds started, and then can make the "parent artifact versions" later .... if deemed important. Do let me know if people have already made such changes, assuming we would ... in which case that might decide the issue?
Updated Equinox to the 4.6.0 parent pom: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=fadccc5c64fa9b9989c11725cdaa0c2740abbd0b http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=3f9256b110eaf8f7b66ce2f6ef64c337ae298f0e http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=caf5d6251236bdbd1de6ac66dcd47ff9976ab5ef
I cd'd into each repo and then ran this command to convert the right versions from 4.5.0-SNAPSHOT to 4.6.0-SNAPSHOT: find . -name pom.xml -print0 | xargs -0 sed -i -s -z -r "s~(<(artifactId|groupId)>(eclipse|tests)[^<]+</(artifactId|groupId)>\s+<version>)4\.5\.0-SNAPSHOT</version>~\14.6.0-SNAPSHOT</version>~g" This worked fine for the platform and jdt repos I've done so far: eclipse.jdt eclipse.jdt.ui eclipse.platform.text I'll proceed with the other eclipse.jdt.* and eclipse.platform.* repos for which I am a committer (all but resources/team). This should also work fine for eclipse.pde* repos, but it wouldn't have worked for rt.equinox.*, since their pom.xml files seem to be less regular than the SDK.
The eclipse.platform.runtime repo used irregular <groupId>org.eclipse.platform.runtime</groupId> instead of <groupId>eclipse.platform.runtime</groupId> Fixed with http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=a1bdfdf33752d943072aae87be30ba5dc30a2717 After that, the only files that needed a manual fix after comment 18 were: eclipse.platform.swt.binaries/bundles/binaries-parent/pom.xml # Most probably stale files: eclipse.platform.ui/releng/org.eclipse.e4.ui.progress.parent/pom.xml eclipse.platform.ui/releng/org.eclipse.e4.ui.progress.update/pom.xml Vikas/Szymon: Please ping me if you're not set up to run that command line and you'd like patches or Gerrit reviews for your repos. Everything else is ready to go.
I believe tonight's N-build http://download.eclipse.org/eclipse/downloads/drops4/N20150702-2000/ mostly was successful, but failed at some of the final "collect and publish" phases. And, the reason for that was related to changes made in comment 15. In addition to the URLs to point to "previous release", there are a few spots where the whole filename is specified too ... using hard coded "4.4" (and usually near, but not necessarily on the same line as the rest of the URL). (And, the fact that "publish" failed, is why the URL is a "dead" URL -- there are some files there, but not the index.php files needed.).
Meant to also add I plan to start another N-build now, after fixing more of the "previous release" properties ... see what breaks next.
I will create R4_5_maintenance branch and update PDE's pom.xml to 4.6.0 today
Updated Platform Workspace repos to the 4.6.0 parent pom: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=9d8f95f6a706da06f46b0138a2cf45d3ef012252 http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=ae779a412b09b6b81ca6b0e5f92bd6c33f576fc9 (In reply to Markus Keller from comment #19) I can see that eclipse.platform.ua and eclipse.platform.ui.tools need to updated as well. Markus, do you plan to take care of that?
Created branches for ssh://git.eclipse.org/gitroot/pde/eclipse.pde.git ssh://git.eclipse.org/gitroot/pde/eclipse.pde.ui.git ssh://git.eclipse.org/gitroot/pde/eclipse.pde.build.git and verified them On Git Bash --------------- ssh vchandra@build.eclipse.org and then git --git-dir=/gitroot/pde/eclipse.pde.build.git branch R4_5_maintenance R4_5 Thanks Markus.
New Gerrit change created: https://git.eclipse.org/r/51322
Gerrit change https://git.eclipse.org/r/51322 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.tools.git/commit/?id=c7c59666abecc0ebf6f43aa62fb37404aed3019c
(In reply to Szymon Ptaszkiewicz from comment #23) > I can see that eclipse.platform.ua and eclipse.platform.ui.tools need to > updated as well. Markus, do you plan to take care of that? Oops, thanks for checking. I already had ua prepared in my workspace, but because EGit's Repositories view doesn't have an indication that the repo is dirty, I missed to commit/push it. ui.tools was missing from my workspace. Both are done now.
For PDE, I updated pom.xml to now have 4.6.0-SNAPSHOT For eclipse.pde.git -------------------- https://git.eclipse.org/c/pde/eclipse.pde.git/commit/?id=55319fe1514de629095cf7fe1dfe4cc9e12ed013 https://git.eclipse.org/c/pde/eclipse.pde.git/commit/?id=ee1bb0098ef68c7cdd217647777a204c6f8de5af For eclipse.pde.ui.git ------------------------- https://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=4ebb63776928b88914bf88bcc3bf261a7debf1f5 https://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=004bf1a3d1b6e3e7d8d2847cf58786f1a1fb4b97 https://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=6946aac7a13013b3eabcf24df45cc899a1c5cebf For eclipse.pde.build.git --------------------------- https://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?id=f63c143bd363b70aef4a599996890c249852143e https://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?id=0b1185cb9dfee747e6bd896e3293b5a1b68d0ddd
(In reply to David Williams from comment #20) > I believe tonight's N-build > http://download.eclipse.org/eclipse/downloads/drops4/N20150702-2000/ > mostly was successful, but failed at some of the final "collect and publish" > phases. And, the reason for that was related to changes made in comment 15. > > In addition to the URLs to point to "previous release", there are a few > spots where the whole filename is specified too ... using hard coded "4.4" > (and usually near, but not necessarily on the same line as the rest of the > URL). > > (And, the fact that "publish" failed, is why the URL is a "dead" URL -- > there are some files there, but not the index.php files needed.). The tests didn't run in latest N-build, because I'd changed previousReleaseVersion to "4.5.0" instead of "4.5". It actually is documented in the comments of streamSpecific.properties it needs to be the "short version" as used in filename, but I just blindly changed 4.4.2 to 4.5.0. Yet another reason I prefer consistent numbering.
(In reply to David Williams from comment #20) > I believe tonight's N-build > http://download.eclipse.org/eclipse/downloads/drops4/N20150702-2000/ > mostly was successful[..] Interesting, because 7 repos still had 4.5.0-SNAPSHOT as parent-pom version. Did the build succeed because it didn't start from scratch but had all the 4.5.0-SNAPSHOT build results already available, so the pending repos just built against an old version that still happened to linger around?
(In reply to Markus Keller from comment #30) > (In reply to David Williams from comment #20) > > I believe tonight's N-build > > http://download.eclipse.org/eclipse/downloads/drops4/N20150702-2000/ > > mostly was successful[..] > > Interesting, because 7 repos still had 4.5.0-SNAPSHOT as parent-pom version. > > Did the build succeed because it didn't start from scratch but had all the > 4.5.0-SNAPSHOT build results already available, so the pending repos just > built against an old version that still happened to linger around? It does start from scratch, does a complete "clean", etc., but I do think the eclipse maven repo is specified somewhere as a "place to get things from" and the parent pom (and pre-reqs ) are published there. I am not really sure if we normally need that (in full production build) ... but, believe it's needed by the "build one plugin" case. (In other words, there *might* be room for improvement here ... but, not really sure).
(In reply to David Williams from comment #31) > (In reply to Markus Keller from comment #30) > > (In reply to David Williams from comment #20) > > > I believe tonight's N-build > > > http://download.eclipse.org/eclipse/downloads/drops4/N20150702-2000/ > > > mostly was successful[..] > > > > Interesting, because 7 repos still had 4.5.0-SNAPSHOT as parent-pom version. > > > > Did the build succeed because it didn't start from scratch but had all the > > 4.5.0-SNAPSHOT build results already available, so the pending repos just > > built against an old version that still happened to linger around? > > It does start from scratch, does a complete "clean", etc., but I do think > the eclipse maven repo is specified somewhere as a "place to get things > from" and the parent pom (and pre-reqs ) are published there. I am not > really sure if we normally need that (in full production build) ... but, > believe it's needed by the "build one plugin" case. (In other words, there > *might* be room for improvement here ... but, not really sure). I've opened bug 471835 to address this issue.
I haven't followed all the comments here, but could the failure in https://hudson.eclipse.org/platform/job/eclipse.jdt.ui-Gerrit/289/console be caused by incomplete changes here? It says: Non-resolvable parent POM for eclipse.jdt.ui:eclipse.jdt.ui:4.6.0-SNAPSHOT: Could not find artifact org.eclipse:eclipse-platform-parent:pom:4.6.0-SNAPSHOT in eclipse-hosted (https://repo.eclipse.org/content/repositories/eclipse/) and 'parent.relativePath' points at wrong local POM @ line 15, column 11 -> [Help 2]
(In reply to Stephan Herrmann from comment #33) > I haven't followed all the comments here, but could the failure in > https://hudson.eclipse.org/platform/job/eclipse.jdt.ui-Gerrit/289/console be > caused by incomplete changes here? > > It says: > Non-resolvable parent POM for eclipse.jdt.ui:eclipse.jdt.ui:4.6.0-SNAPSHOT: > Could not find artifact > org.eclipse:eclipse-platform-parent:pom:4.6.0-SNAPSHOT in eclipse-hosted > (https://repo.eclipse.org/content/repositories/eclipse/) and > 'parent.relativePath' points at wrong local POM @ line 15, column 11 -> > [Help 2] Sort of. We are not deploying the 4.6 version yet. See bug 471333.
I have aggregator ready to build "maintenance" too. So far, just used tag R4_5 for all submodules. BUT, I would like to address bug 471732 as we get started, meaning that the parent pom, and all that ripple effect would have to change to "4.5.1". If no objections received by ... say 3 PM Eastern ... then I'll assume we are doing it, and will make changes to parent pom. All other repos will then need to be branched, if, for no other reason, to update the parent pom version they refer to. Hence, will use R4_5_maintenance in repositories.txt file.
Given there's been no complaints, or alternatives suggested, I'll assume the "4.5.1" solution is fine with everyone. I'll make that change now. Component leads, please make corresponding changes for R4_5_maintenance. (And, sorry, you can't just wait for the build to fail, since we do not do many maintenance builds, and because of bug 471835. Thanks,
I've completed the branching (when needed) and parent pom updates for these four repositories: eclipse.platform.releng.aggregator eclipse.platform.releng eclipse.platform eclipse.platform.common
I have updated the following repositories for parent version: eclipse.jdt.core.binaries eclipse.jdt.core
Updated the repositories: org.eclipse.jdt.debug org.eclipse.platform.debug
I've updated the parent pom version references for: eclipse.platform.swt eclipse.platform.swt.binaries
I updated Equinox repos parent poms for R4_5_maintenance: rt.equinox.bundles rt.equinox.framework rt.equinox.p2
I'll update PDE's pom.xml tomorrow morning ( india time). That should be well before 10am EST wednesday time.
Created attachment 255045 [details] patch to increment binaries parent (artifact) (In reply to Arun Thondapu from comment #40) > I've updated the parent pom version references for: > > eclipse.platform.swt > eclipse.platform.swt.binaries In local test builds (which fail) I see a number of errors that say things similar to: [ERROR] Non-resolvable parent POM: Could not find artifact eclipse.platform.swt.binaries:binaries-parent:pom:4.5.1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 16, column 11 -> [Help 2] org.apache.maven.model.resolution.UnresolvableModelException: Could not find artifact eclipse.platform.swt.binaries:binaries-parent:pom:4.5.1-SNAPSHOT I believe this is simply due to forgetting to increment the artifact version, in binaries parent. (as illustrated with the patch). [I've not test this, but pretty sure it should be incremented.]
Created attachment 255047 [details] repository pom needs incremented The previous patch did solve the problem with SWT bundles. (in my local testing). The next problem was with the jdt.debug bundles ... appears the "repository pom" was omitted in the change. Two lines need incrementing, as illustrated in the patch.
(In reply to David Williams from comment #44) > Created attachment 255047 [details] > repository pom needs incremented > > The previous patch did solve the problem with SWT bundles. (in my local > testing). > > The next problem was with the jdt.debug bundles ... appears the "repository > pom" was omitted in the change. Two lines need incrementing, as illustrated > in the patch. The next problem was "platform debug". It too needs it's "repo pom" incremented (2 lines) similar to the jdt debug. After that, it was something related to jdt.core (and parent) but didn't really look any closer than glancing at the log (just due to fatigue :) If/when the Wednesday M-build needs a respin, I'll wait to hear requests on platform-releng-dev list. (Since I may be on and off-line, in the morning).
Thanks David. "repository pom" updated for jdt.debug and platform.debug
For 4.5.1 in PDE, I updated pom.xml to now have 4.5.1-SNAPSHOT For eclipse.pde.git -------------------- https://git.eclipse.org/c/pde/eclipse.pde.git/commit/?h=R4_5_maintenance&id=2c13849ccd5cfe12d032f2dcb0fe16e1fd86a2fd For eclipse.pde.ui.git ------------ https://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?h=R4_5_maintenance&id=1dc328bbe264d4ebefef0f013bb8a90b5deba55e For eclipse.pde.build.git ---------------------------- https://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?h=R4_5_maintenance&id=a2fddde0f2866abc72a94c3df68fbf7a6cf22f81
(In reply to Vikas Chandra from comment #47) > For 4.5.1 in PDE, I updated pom.xml to now have 4.5.1-SNAPSHOT > > For eclipse.pde.git > -------------------- > https://git.eclipse.org/c/pde/eclipse.pde.git/commit/ > ?h=R4_5_maintenance&id=2c13849ccd5cfe12d032f2dcb0fe16e1fd86a2fd > > > For eclipse.pde.ui.git > ------------ > https://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/ > ?h=R4_5_maintenance&id=1dc328bbe264d4ebefef0f013bb8a90b5deba55e > > For eclipse.pde.build.git > ---------------------------- > > https://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/ > ?h=R4_5_maintenance&id=a2fddde0f2866abc72a94c3df68fbf7a6cf22f81 I think you've made error similar to the swt one, above. In your repo pom, you correctly changed it's parent to 4.5.1, but your eclipse.pde.ui artifact you left at 4.5.0 ... but is is *that one* that your individual project pom's point to as their parent. Both should be "4.5.1". <parent> <groupId>org.eclipse</groupId> <artifactId>eclipse-platform-parent</artifactId> <version>4.5.1-SNAPSHOT</version> <relativePath>../eclipse-platform-parent</relativePath> </parent> <groupId>eclipse.pde.ui</groupId> <artifactId>eclipse.pde.ui</artifactId> <version>4.5.0-SNAPSHOT</version> <packaging>pom</packaging>
(In reply to David Williams from comment #36) > Given there's been no complaints, or alternatives suggested, I'll assume the > "4.5.1" solution is fine with everyone. > > I'll make that change now. Component leads, please make corresponding > changes for R4_5_maintenance. (And, sorry, you can't just wait for the build > to fail, since we do not do many maintenance builds, and because of bug > 471835. > > Thanks, Does it mean a similar change but regarding "4.5.2" will need to be made for R4_5_maintenance after 4.5.1 is released in order to prepare for 4.5.2?
(In reply to Szymon Ptaszkiewicz from comment #49) > Does it mean a similar change but regarding "4.5.2" will need to be made for > R4_5_maintenance after 4.5.1 is released in order to prepare for 4.5.2? ... and then also another change after 4.5.2 is released to prepare for LTS builds (e.g. change to "4.5.3" or something else but higher than "4.5.2")?
(In reply to David Williams from comment #43) > I believe this is simply due to forgetting to increment the artifact > version, in binaries parent. (as illustrated with the patch). [I've not test > this, but pretty sure it should be incremented.] Thanks David! Incremented artifact version and pushed.
>>I think you've made error similar to the swt one, above Now corrected in PDE. Thanks David ! Please let me know if something else is amiss.
Updated Platform Workspace repos to the 4.5.1 parent pom: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?h=R4_5_maintenance&id=ebac77a315e65beed148f3a3ffb1391c0b13b12d http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?h=R4_5_maintenance&id=d1d84b91c71e5fd248307f0a212da1501e8d198f
I've updated parent poms for R4_5_maintenance for eclipse.jdt eclipse.jdt.ui and fixed an incomplete update in eclipse.jdt.core Also pushed the 4.5.1 updates for the remaining eclipse.platform.* repos. Vikas: eclipse.pde.build/pom.xml needs to update the other 4.5.0 to 4.5.1 as well. David: I saw that eclipse.platform.releng/tests/eclipse-releng-test-parent was not updated, but maybe this folder is not actually in use. For the platform, jdt, and pde repos it's really not hard do to do this correctly: - run this script in all git repos you want to update from 4.5.0 to 4.5.1: find . -name pom.xml -print0 | xargs -0 sed -i -s -z -r "s~(<(artifactId|groupId)>(eclipse|tests)[^<]+</(artifactId|groupId)>\s+<version>)4\.5\.0-SNAPSHOT</version>~\14.5.1-SNAPSHOT</version>~g" - in EGit, for each repo: - select repo in Git Repositories view - open the Git Staging view - click Refresh - check the changes and commit/push
New Gerrit change created: https://git.eclipse.org/r/51577
Gerrit change https://git.eclipse.org/r/51577 was merged to [R4_5_maintenance]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?id=55f9089f81fc5d22f8179539fc025cb936a20633
(In reply to Szymon Ptaszkiewicz from comment #49) > Does it mean a similar change but regarding "4.5.2" will need to be made for > R4_5_maintenance after 4.5.1 is released in order to prepare for 4.5.2? Yes. (In reply to Szymon Ptaszkiewicz from comment #50) > ... and then also another change after 4.5.2 is released to prepare for LTS > builds (e.g. change to "4.5.3" or something else but higher than "4.5.2")? Hmmm, not sure. (You really think ahead, eh? :) I don't think so, I think for LTS, we are not "preparing for a new (service) release" ... we are are simply "providing patches/fixes for an existing release". I suspect we could handle LTS either way, so am open for discussion. But that is my initial view of it. (In reply to Markus Keller from comment #54) Thanks Markus, for the updates, and explicit directions.
(In reply to Markus Keller from comment #54) > and fixed an incomplete update in eclipse.jdt.core > - run this script in all git repos you want to update from 4.5.0 to 4.5.1: Thanks Markus. This is one (of the) use case where one can't rely solely on the IDE. I have fallen for it (again) - even though I did think of the root pom, missed the test pom.
Excellent work! Both builds running so quickly! It's possible that bug 471835 might reveal some issues, but we'll handle them in separate bugs, if so. Thanks everyone!
