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

[Nick Boldt]

 > If our build process continues to enforce/require full rebuilds of
> everything then we keep having this uncertainty about how much was
> actually affected in this release ? how much do we need to test ?

Today our requirements for tracking which projects feed the aggregates
are *three tiny pieces* of information:

a) build with the MINIMUM target platform
b) test with the MAXIMUM target platform
c) use the correct BUILD_ALIAS
d) SPOILER ALERT, there's a 4th piece too - see below.

All three of those *can be set in Jenkins* - in fact we set the first
*two* already (we only set BUILD_ALIAS for JBDS to force it to be GA
instead of Final).

Then we would only need to *encourage* people to use the latest parent
pom for local testing, and not actually need it for running builds. But
IMHO the Task JIRAs force people to run local tests, and gentle
encouragement will lead to things NOT getting done.

--

If you'd like we can test this approach with the 8.1.0 builds in
Feb/March. As long as BUILD_ALIAS & the max target target platform
version (something like 4.42.0.*) are incremented in Jenkins (to move
through Beta1/CR1/Final/GA), and all the projects w/ changes have
properly upversioned their plugins/features where necessary, everyone
can continue to use the 4.2.1.Final-SNAPSHOT version of the parent pom.

Enforcing we all use the latest parent pom is a convention... but it
isn't *strictly necessary* after we drop a x.y.0.Final (as long as
Jenkins has the correct information needed).

(It is required for 4.3.0.before-Final builds because the value of the
*minimum* target platform IS changing every month or so, and we're
adding variables to support migration of integration tests out of the
unit test suites, etc. So for the ramp up to the 0.Final, we DO need
everyone using the latest parent pom.)

---

HOWEVER... there is a fourth reason to use the latest parent pom.

Our parent pom defines the list of upstream sites used when building the
individual projects (eg., Server depends on Base), which for 4.2.1.Final
includes two unchanged project sites: Hibernate and LiveReload.

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

For master branch, everything will be new, so we use all the staging
(nightly) sites:

https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml#L65-L96

This list is also used when creating the composite site we use to
determine that:

* everything in the site can be co-installed (using headless p2.director
installation test)

* if there are changes to the contents of one or more project, the
aggregate will be rebuilt to pick up those upstream changes, and we'll
see failures as soon as possible*

So again, this is important for x.y.0.before-Final builds, but not for
x.y.z.maintenance builds (since those minor changes should be compatible.

> If we know -in this release livereload and hibernate changed - nothing
> else; then we can limit our testing to anything reliant on those
> changes.

Interesting example... you list the two projects out of 17 which in fact
have no commits in github 4.2.x branch since 4.2.0.Final release. :D

* - for example, recent refactorings in Server's AS Tools test plugins
in master have caused webservices tests to fail due to a missing
dependency.

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