Re: [jbosstools-dev] ACTION REQUIRED: Prepare for 4.2.1.Final / 8.0.1.GA (release is next week Dec 15 2014)

Max said: We didn't "release" Birt and Portal. We only "released" JBT which contained those. We DID "release" the handful of components [1] that said they were not doing changes for 4.2.1 - Aerogear, Freemarker, Hibernate, Livereload, and Webservices . However, of those, only livereload and Hibernate remain unchanged, as well as parts of Central - everyone else has now contributed fixes into 4.2.1. So 60% of the effort to cache those 4.2.0.Final versions was wasted. [1] http://download.jboss.org/jbosstools/updates/stable/luna/core/ Ah, but you see, the check is "has the source changed" not "has anything but one line in the root pom changed". Since the source changed, the /staging/ folder w/ the 4.2.0.Final bits was updated to include the new BIRT and Portal stuff. From your perspective, nothing changed. From github's perspective, there was a new SHA, and therefore the code needed to be rebuilt. 3 things: a) GA release process does normally include publishing all the components to their own folder under [1]. Because in the past, 99% of the components have changed during maintenance, so the effort to return (noise to signal) was too high. Even with this release, we tried to not build 5 of the 17 projects, and then ended up rebuilding 15 of them. b) changing the check in Jenkins jobs from "check Github for changes" to "check Github for changes that are different than just updating the root pom to point to a newer parent pom" c) educating people to the fact that they do NOT need to bump their root pom's reference to a newer parent pom IFF there are no OTHER changes in the repo since the previous .Final/GA release. Had Birt and Portal not been actually changed, (a) and (b) would have not been needed, as there would have been no fresh publish, and I could have just pulled the old staging bits into [1] for safe keeping. -- So long story short, if it's really important that these two components NOT release new timestamped versions of the same bits (which were run w/ fresh tests using the updated target platform), then yes, I can rebuild using [2] as the input for their bits to the composite [3] and aggregates [4]. However I don't like doing that because it will also include lots more than we want -- duplicate versions of other projects' bits, which are probably safe, but we've never done that before so I'm hesitant to start now. [2] http://download.jboss.org/jbosstools/updates/stable/luna/ [3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2.... [4] https://github.com/jbosstools/jbosstools-build/blob/jbosstools-4.2.x/pare... and https://github.com/jbosstools/jbosstools-build/blob/jbosstools-4.2.x/pare... -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com