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

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