Actually, we are already using the 2.0 trunk as an experiment trunk, take the maven build feature and jpa refactoring work as examples.
So here is my binding +1. Regards Jeff On Wed, May 12, 2010 at 3:37 AM, Tammo van Lessen <[email protected]>wrote: > 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 > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
