Re: AW: [jbpm-dev] No more jBPM 3 releases?

everyone would just commit *their* fixes for *their* use case. not a lot of users would be able to tell if they break other people's code when 'fixing' a jbpm bug. regards, tom. Koen Aers wrote: > 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 -- regards, tom.