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

Tue Jun 16 09:21:22 EDT 2009

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 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
> 

-- 
regards, tom.