[wildfly-dev] WildFly Core component upgrade coordination

[Stuart Douglas]

I think that a big problem with this approach is that there is always 
going to be another task that should be done and another reason to hold 
the core release by just a few more days.

I don't really think that we need this level of process around a Wildfly 
Core release. I think that we should just be doing these releases fairly 
frequently, and if some work misses the release then there is always 
another release coming up in the near future.

I think that a JIRA that tracks what is waiting on the next WF core 
release is a good idea, as it lets us see what is blocked waiting on the 
next release, however I don't think we should be holding up a core 
release based on work in the pipeline.

Stuart



David M. Lloyd wrote:
> If you are assigned a JIRA for WildFly that requires a change to WildFly
> Core (either a direct fix or a component upgrade), there (obviously)
> needs to be a WildFly Core release and upgrade into WildFly proper
> before the change can be completed. But because we're all asynchronous
> here, coordination is something of a problem.
>
> So, to organize things a bit, I've opened
> https://issues.jboss.org/browse/WFLY-3945 for upgrading WildFly Core to
> 1.0.0.Alpha9.
>
> If you have a WFCORE task or component upgrade that you think should be
> finished before the upgrade happens, add the corresponding JIRA as a
> dependency to that issue. If a WFLY task is blocked waiting for the
> WFCORE upgrade, add that task as a dependent (in other words, add
> WFLY-3945 as a dependency to that task; you can do it either way though).
>
> If the list gets too large, we'll have a discussion about splitting the
> work between Alpha9 and Alpha10 (or whatever is next).
>
> Keeping the work organized around this issue will remove some of the
> confusion around what needs updating and when, and why.