From https://jira.jboss.org/jira/browse/JBPM-2263

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.

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.

i think we need to spend most bugfixing efforts on jbpm 4.

-- 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(a)lists.jboss.org] *Im Auftrag von *Ronald van Kuijk > *Gesendet:* Dienstag, 16. Juni 2009 11:59 > *An:* jbpm-dev(a)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 > https://lists.jboss.org/mailman/listinfo/jbpm-dev > _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

> 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

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.