[Hawkular-dev] is it time for a bom? or for version definitions in parent pom?

Jay Shaughnessy jshaughn at redhat.com
Wed Dec 16 10:22:00 EST 2015


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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20151216/e525e58a/attachment-0001.html 


More information about the hawkular-dev mailing list