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.
* release dates should be in Jira, should be based on the next
hawkular release, and should be reliable
o jiras should have Fix versions assigned as best as possible to
reflect what is going to be in the release
o slips, breaking changes, etc must be made very public
o stability should start to take precedence over refactoring/elegance
* back compat/stability: it would be nice if a component/hawkular did
not *have* to always upgrade to the latest version of a dependency.
* updating hawkular pom with a srcdep version means hawkular requires
the upcoming .Final release
* srcdeps removed/.Final versions updated in the hawkular pom prior to
hawkular milestone:
o at least 7 days prior: parent, bus, commons, accounts, command
gateway,
o at least 5 days prior: inventory, alerts, metrics, agent, BTM
(when it is incorporated)
o at least one day prior: console
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev