+1 from me as well
I'm also skeptical that separate releases will prove workable without
separate JIRAs, however I think we can cross that bridge when we come to it.
There may also be a bit of a middle ground here. One of the reasons a
separate JIRA instance for Proton was an easy decision is tha
On 04/11/2013 03:37 PM, Ted Ross wrote:
+1
As you point out, Justin, we've already taken this step with Proton without too
many difficulties. This looks like a major improvement to me.
It will be desirable for each library component to have a well-defined,
constrained, and stable API. This wi
+1
As you point out, Justin, we've already taken this step with Proton
without too many difficulties. This looks like a major improvement to me.
It will be desirable for each library component to have a well-defined,
constrained, and stable API. This will be difficult if we separate the
C+
+1 on the general concept, details to be figured out...
On 04/10/2013 09:55 AM, Justin Ross wrote:
Hi, everyone. We've recently been discussing the components of our
project in a couple different contexts. This is a proposal to take
the outcomes of those discussion and apply them to how Qpid i
>From a user point of view ... if the client libraries have independent
releases, it might be more clear to many people that they do not need to
use exactly the same version of the client library as is the broker
version. That seems to be quite popular believe among the people connecting
to our bro
+1 from me as well. I think this would be a good improvement on the
existing structure and benefit everyone by allowing for schedules more
tailored to the specific components, and in turn enable us to better meet
the needs of their users.
We would need to investigate how some of the changes might
On Wed, Apr 10, 2013 at 09:55:22AM -0400, Justin Ross wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
+1
--
Darryl L. P
+1 on this.
Having the flexibility to have individual release cycles for each component
will be huge advantage for us.
However as Justin mentioned, we shouldn't rule out a Qpid wide release
perhaps once a year or so.
>From a users perspective this is a great thing to have, bcos all the
components b
I'm +1 this... Obviously we need to understand better the amount of work to
achieve the separation of the components... but if this were in place then
we wouldn't be facing the sort of issues we are currently experiencing with
the 0.22 release which would strongly benefit from not having the releas
Hi, everyone. We've recently been discussing the components of our
project in a couple different contexts. This is a proposal to take
the outcomes of those discussion and apply them to how Qpid is
organized.
Thanks for taking a look,
Justin
## Related discussions
-
http://qpid.2158936.n2.nab
10 matches
Mail list logo
