Hi,

here is my binding +1.

The 1.x branch has never been discontinued and that way things went out
of sync. Having two development branches did not work, so although it is
pity that we failed to stabilize trunk, we should clean up the
situation, declare 1.x to what it currently is, namely trunk and then
try later to move features step by step from the former trunk to the new
1.x based trunk. It took me a while to feel comfortable with this
solution, but I don't see any alternative.

Cheers,
  Tammo

Rafal Rusin wrote:
> Hello,
> 
> let's start a vote for moving trunk into experimental branch and 1.X
> back to trunk.
> Later (I think after 1.3.5 release), we'll continue 2.X versioning in
> trunk and focus on redesign a few important parts of ODE (like for
> example removing binary serialization of execution states in favor of
> XML serialization).
> 
> I think this move is one of the most important decisions for the project now.
> So what we have now is ODE-1.X in production and old fork ODE-trunk,
> which is not.
> We also have a lot of issues for 1.X in production (check out fix for
> 1.3.5 
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310270&fixfor=12314243&resolution=-1&sorter/field=priority&sorter/order=DESC).
> The obvious thing is that we have to stabilize 1.X and make people
> happy for using it.
> We also have to make 1.X better code quality, more documented,
> redesign for example message broadcasting, add bpel validation (David
> Carver is doing it), etc., etc.
> So basicly, we have a situation where we also want some of new
> features to be implemented in 1.X. This contradicts to having current
> ODE-trunk, where new features go.
> 
> So, we have current ODE-trunk, which costs us 2 times more developers' power
> to migrate all changes, because it's very desynchronized. Moreover
> newcomers, tend to make contributions to ODE-trunk, which is bad,
> because it doesn't bring higher quality to whole product.
> 
> So for me it's obvious we should drop current ODE-trunk ASAP and merge it's
> new features in smaller steps, still staying with latest 1.X in production.
> This way we'll focus our efforts on something we use. And using
> product in production makes it's real value.
> 


-- 
Tammo van Lessen - http://www.taval.de

Reply via email to