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

[Nick Boldt]

Max said:
> Nick - if our build deletes our actual released bits and not allow using
> the previous bits then that is a problem.

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/

> Did the check for publish fail to detect there was no change ?

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.

> We have had and will have this situation for others than just "dormant"
> modules like birt and portlet so we should be able to handle this by now
> IMO.
> What is missing ?

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.luna/
[4]
https://github.com/jbosstools/jbosstools-build/blob/jbosstools-4.2.x/parent/pom.xml#L73 

and
https://github.com/jbosstools/jbosstools-build/blob/jbosstools-4.2.x/parent/pom.xml#L79

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com