I agree with Juca, I think this is going to be solved only with process.  We are waiting until the last moments before a Hawkular release to make component releases and that is killing us.  I don't think Juca's proposal goes far enough in that I think the release dates should be earlier; for base components, a week of planned quiet time prior to the hawkular release.  Furthermore, I think the components are getting mature enough to stick to a release schedule.  Now  we, the developers,  need to be mature enough to apply more discipline to what we are producing.

On 12/16/2015 4:52 AM, Juraci Paixão Kröhling wrote:
On 16.12.2015 10:35, Peter Palaga wrote:

I still think that speaking with one's upstream before releasing is the
most flexible and reliable way of solving the present problem.

+1 . The problems discussed in this thread are, IMO, inherent to our 
modular design. I certainly don't want an update to Accounts to be 
propagated right away to all components, as a bug there might block 
someone in a downstream component. What I certainly would want is to 
have all components updated to the same accounts version by a given date.

I'm still convinced that we need some sort of code freeze, or, at least, 
a component freeze, like any multi-module project with complex 
dependencies have, such as a Linux distribution.

My suggestion (based on our current dependency graph):
- Thursday before the release: Parent, Commons and Accounts
- Friday before the release: Inventory, Metrics, BTM
- Monday before the release: Command Gateway, Agent, Alerts
- Tuesday (release day): Hawkular

This should give us enough time to fix any last-minute issues.

- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev