On 16 Nov 2014, at 17:11, Nick Boldt wrote:
If you're a dev or QE for projects which use Tern, AngularJS, or
Thym,
or any other upstream incubating / frequently-changing dependency,
please *read and reply* if this approach seems reasonable to you.
---
For dependencies like Tern, AngularJS and Thym, instead of iteratively
updating them every few weeks in the target platform, we could instead
treat them like jbosstools-* components, and simply refer to them as
<dependencies> within dependent projects' root poms.
Last week we said that was possible for thym. Not sure if a unified
approch will work well for tern and especially angularjs.
We used to do this for "moving target" upstream
dependencies like
m2e-*
extensions,
which ones ? the ones we have inside jbosstools github ? those are
different beasts than tern, angularjs, thym because
these actually exist *outside* our releases.
but for JBDS 8 we put EVERYTHING into the target platform
and it was a bit of a pain to manage.
We could go a step further, too, and do automated weekly pulls of new
upstream deps.
For thym - maybe. Gorkem's call.
For angularjs/tern - if we don't follow the changes closely and have
test for verifying we are still working
then I would be really hesitant toward this.
---
The process would look like this:
* every Friday, a Jenkins job pings
eclipse.org looking for the latest
available Tern, AngularJS, and Thym builds.
* if a newer one is found, a mirror is pulled and added to the pile on
http://download.jboss.org/jbosstools/updates/requirements/
how do we keep track on which can be cleaned up/removed and which need
to stay ?
this won't work reliably when we multiple streams building. Which stream
uses what then ? and how does it get locked down for release ?
* projects which wish to build against these newer deps can do so by
choice (local experiments) or automatically by updating their root
poms
to include new <repository> entries:
https://github.com/jbosstools/jbosstools-jst/blob/master/pom.xml#L23-L27
* projects will then need to monitor their manifests/feature.xml files
to ensure they depend on the correct versions of upstream deps:
https://github.com/jbosstools/jbosstools-jst/blob/master/plugins/org.jbos...
* should they forget, their build will break w/ an obvious error
message
this only applies to tern/angularjs because no stable api in the areas
we rely.
* they can then apply a fix & rebuild, or rollback to an earlier
upstream dep in their root pom's <repository> reference, if they're
not
able to move up to the newer Tern. Angular, or Thym dependency.
you want to allow each component to be able to say they use different
version of tern, angularjs or thym ?
How do we ensure our builds will actually be compatible with each other
?
Thats my biggest headache with these.
I dont think an alternate repository reference should be allowed into
the stream's. They need to use the one defined by parent.
forks/feature branches can use it for testing new things, but when
integrating it to master the versions need be aligned, wont you say ?
/max
http://about.me/maxandersen