Wouldn't it be good to leave the responsibility for additional jBPM 3
releases entirely to the community? I mean, if there would be a need
in the community e.g. for further 3.3.x releases (with new features)
than it should be possible for them (them being community minus the
core team) to do so. On the other hand, the core team focuses on the
bugfixes, stabilization and productization of jBPM 4.
Just some ideas that came across my brain...
Cheers,
Koen
Op 16-jun-09, om 07:49 heeft Tom Baeyens het volgende geschreven:
> But this is a different statement compared to 'there are no
more
jBPM3
> releases planned'). Would make a lot of sense to make this fully
clear
> in the community.
right. making this more clear and explicit is good.
the situation is that after the current product release, there are
no platform releases planned in which jbpm 3 is included. so from
that angle, we should not expect a lot of bug fixes to come from
that direction.
> Effectively jBPM 3 goes into a maintenance mode where
> paying customers drive the possibility of next releases'.
the customer fixes are committed on the product branch jbpm-3.2-
soa. the product consumes directly from that branch. meaning there
no need for a jbpm community release in order for the product to get
those fixes.
both for customers and for community users we should be able to fix
and release major bugs. but i want a very tight filter on that for
*only* the major bugs.
given the stabilization that jbpm 3 already had, i think not a lot
of those should come out. and hence i don't think we'll see a lot
of subsequent releases.
so imo, it will all depend on what kind of bugs we encounter on jbpm
3.
> But does this
> mean I should not put in any fixes anymore (not that I did that a
lot,
> but others did) just to prevent possible regressions?
as said above, we need to apply a very tight filter to maintain
stability on jbpm 3 and allow us to make more progress on jbpm 4.
so discuss much more then before on what you want to fix on jbpm 3.
i only want major bugs to be fixed in jbpm 3 code base. there is
too much risk of breaking things. i have had several occasions
where i fixed a bug because someone wanted it and then ended up
spending a lot of time fixing the collateral damage. in many cases
it was just not worthed.
> Or should I only
> put them in trunk?
if we decide to fix it, we should do it in the product branch. that
is the only branch that we'll maintain going forward.
> Or? Please guide us ;-)
let's summarize with these guidelines:
1) if bugs are fixed, they should be fixed in the jbpm3.2-soa branch.
2) we should apply a very tight filter of issues that we fix to
avoid the risk of regression
3) whether we do a community release will depend on what kind of
issues we'll encounter
does that help ?
regards, tom.
Ronald van Kuijk wrote:
> 2009/6/16 Tom Baeyens <tbaeyens(a)redhat.com <mailto:tbaeyens@redhat.com
> >>
> for making the release, there is only the effort of releasing.
> that
> is not a lot of effort so we can do it once and a while. so rest
> assured. it's not a political decision.
> jbpm 3 already went through a lot of stabilization. so there is
> also the risk that if we fix something, that we introduce another
> problem.
> So it is not only the effort of releasing, but also some additional
> QA (Stabilization != full QA, I know) ? Otherwise you would not be
> so reluctant (besides putting in the effort to fix the issue itself)
> but for fixing the bugs, we are not proactively fixing all the
> bugs
> that people report on jbpm 3. we currently intend to only fix
> those
> that come from clients. and even for those reports we evaluate if
> the risk of introducing new problems when fixing the given bug.
> But this is a different statement compared to 'there are no more
> jBPM3 releases planned'). Would make a lot of sense to make this
> fully clear in the community. Effectively jBPM 3 goes into a
> maintenance mode where paying customers drive the possibility of
> next releases'. But does this mean I should not put in any fixes
> anymore (not that I did that a lot, but others did) just to prevent
> possible regressions? Or should I only put them in trunk? Or?
> Please guide us ;-)
> i think we need to spend most bugfixing efforts on jbpm 4.
> I do not disagree with this, but I also agree with Bernd, jBPM 3
> has a broad installed base. For me, jBPM 3 should at least have one
> more year of more development than what you suggest.
> -- regards, tom.
> Bernd Rücker wrote:
> I thought as well that there will be bug fix releases (and
> maybe
> even some new features if it really make sense). Why not?
> There
> are a lot of jbpm 3.x users out there which will keep using
> it…
> *Von:* jbpm-dev-bounces(a)lists.jboss.org
> <mailto:jbpm-dev-bounces@lists.jboss.org>
> [mailto:jbpm-dev-bounces@lists.jboss.org
> <mailto:jbpm-dev-bounces@lists.jboss.org>] *Im Auftrag von
> *Ronald van Kuijk
> *Gesendet:* Dienstag, 16. Juni 2009 11:59
> *An:* jbpm-dev(a)lists.jboss.org <mailto:jbpm-dev@lists.jboss.org
> >
> *Betreff:* [jbpm-dev] No more jBPM 3 releases?
> >From
https://jira.jboss.org/jira/browse/JBPM-2263
> Tom Baeyens
>
<
https://jira.jboss.org/jira/secure/ViewProfile.jspa?name=tom.baeyens%40jb...
> >
> - 15/Jun/09 03:45 AM
> there are no more releases planned for jbpm 3
> Is this true? Only SP releases for bugfixes? But isn't this a
> 'bug'? The schema allows it.
>
> ------------------------------------------------------------------------
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev(a)lists.jboss.org <mailto:jbpm-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/jbpm-dev
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev(a)lists.jboss.org <mailto:jbpm-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/jbpm-dev
--
regards, tom.
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev