Re: [jbosstools-dev] ACTION REQUIRED: Prepare for 4.2.1.Final / 8.0.1.GA (release is next week Dec 15 2014)
> 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