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

[Max Rydahl Andersen]

>> I would say so - we have the 4.2.0.Final updatesite to get these from 
>> so
>> sounds weird why we need to update these.
>>
>> The whole intent we are going for is to *not* burden users with more
>> bits to download AND avoid QE having to test/verify new binaries.
>
> The idea is nice, but I'm not sure this can actually ever work. The 
> target platform was changed anyway (including common/foundation JBT 
> plugins). So theoretically you can never be 100 % sure that JBT 
> 4.2.1.Final will work with the older portlet.
> So you can never say that no testing is needed. I'm actually not sure 
> how much difference it makes - if you know that there were no changes 
> but the bits are newly built as opposed to using exactly the same bits 
> - in both cases you need at least some smoke testing.

I'm not saying *no* testing, I'm saying no need to test *new* binaries.

My insistence on making us capable of making the most minimal rebuild is 
not me expecting that from the first time we do this we can do less 
testing.

It is me expecting that if we can get our builds *automatically* be 
minimal and not require massive rebuilds, updates of parent poms and 
lots of other churning and  just make it a few mb's of updates for a few 
set of components then we are much better prepared to do faster and 
faster releases.

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 ?

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

> But I agree from use perspective it's probably nicer if they need to 
> update less bits.

Yes, this too.

/max