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

Koen Aers koen.aers at jboss.com
Tue Jun 16 09:18:02 EDT 2009 

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 at redhat.com <mailto:tbaeyens at 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 at lists.jboss.org
>>        <mailto:jbpm-dev-bounces at lists.jboss.org>
>>        [mailto:jbpm-dev-bounces at lists.jboss.org
>>        <mailto:jbpm-dev-bounces at lists.jboss.org>] *Im Auftrag von
>>        *Ronald van Kuijk
>>        *Gesendet:* Dienstag, 16. Juni 2009 11:59
>>        *An:* jbpm-dev at lists.jboss.org <mailto:jbpm-dev at 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%40jboss.com 
>> >
>>        - 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 at lists.jboss.org <mailto:jbpm-dev at lists.jboss.org>
>>        https://lists.jboss.org/mailman/listinfo/jbpm-dev
>>    _______________________________________________
>>    jbpm-dev mailing list
>>    jbpm-dev at lists.jboss.org <mailto:jbpm-dev at lists.jboss.org>
>>    https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
> -- 
> regards, tom.
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev

More information about the jbpm-dev mailing list