Sylvain Wallez dijo: > Antonio Gallardo wrote: > >>Sylvain Wallez dijo: >> >> >>>Yep. And posts like Barzilai's one make me wonder if we should stop >>> development in the 2.1 repo and move it over to 2.2 into a new >>> "cforms" (Cocoon forms) block. Note that this doesn't prevent to >>> backport this block to 2.1 before an official 2.2 release if we >>> consider that it has reached some level of stability (including docs). >>> >>> >> >>-1. I think woody need to get improved even faster than the current >> trend in the current release too. 2.2 is far away and since it will be >> at a stable level this would slowdown the development of woody. :-( >> >>If someone wants to work with a "non-moving target" then there is 2.1.x >> > > I guess you misunderstood what I was saying, as you're stating more or > less my thoughts (if I understand correctly): what I'm suggesting is to > move the development to the 2.2 repository, but make updates to the 2.1 > repository when we consider to have reached a stable milestone on the > *cforms block*, and not the entire Cocoon repository.
Hi Sylvain, I cleary understand what you had in mind. Please note woody is still marked as an alpha block. So we are free to make any changes without worrying about back compatibility or similars. This is a fact. If we right now move to 2.2, I bet the woody development will slowdown for 2 reasons: 1) Woody testers (as me) will not currently move to 2.2 until it will reach some stable milestone. This is not because I don't want to support 2.2 development, but because I need to end a project. > This would avoid people working with the 2.1 branch to be too much > disturbed by this moving target. The 2.1 branch will only have steps > corresponding to the milestones of the continuous development occuring > in the 2.2 repo. OK. Check the pro and cons. Suppose you made another incompatibility change to cforms. So later you will move it to woody. I don't think this is a good idea. I think the pain must be fast and as soon as posible. In my lazy mind, if I see there is a future change that will break all my work, then I think: Why to continue, if at the end I will need to rework all this stuff? So this is not too smart to just delays changes from repo 2.2 to 2.1. This is why I prefer to get the changes right now and work with this. As I posted before, for people that does not want a "moving target" then they can use any of the release or any fixed CVS version. But soon or later they will move to 2.2. For example: if they choose to use some nice features of Cocoon 2.2. What will be there: Woody forms does not exist at all, se then? By my own experience working with the moving target means: Monitor the cocoon-cvs: To see if a posted change is important to you. For example: If there are just a website update (typo fixing), then this will not affect you current development. You don't need to run all updating procedure for this type of cvs posts. When an interesting cvs update happens: 1- Backup your project and update Cocoon CVS. 2- See if the changes on the CVS have a direct impact in your application. For example: if you are working with woody, so check the changes related to woody tags, etc. 3-Build the new cocoon and import your project. 4-Test if your project works with the new version. 5-If the project does not work, try to fix it. 6-If after fixing there are other problems (example: a Cocoon internal): 6.a) Inform in the mail list about the problem 6.b) go back to the backup copy of the project 6.c) stay tunned to see if in the CVS is a fix of the error. I learned to work in this way. I do this every 1 to 7 days. It depends of the level and importance of changes to my current work. I do this for 2 types of applications that use diferents blocks config. Maybe this is additional work and I am crazy. I know. But I love to see and use every new features and bug fix in Cocoon. I hope this explain my view point. Best Regards, Antonio Gallardo >>I was working in druid - http://druid.sf.net/ for get the boring O/R >> mapping done by a Druid generator. >> > > This thing is very interesting as, although DB and O/R mappings are not > Cocoon's concern, having a full working template in Cocoon greatly helps > people to build complex apps. You are right, but I do this to show people that there is a faster and easier road to build database-oriented web applications with Cocoon. Cocoon is also a moving target it self: 1-Web publishing framework 2-Webapp framework. And I am pointing to: 3- RAD webapp framework. When I started with Cocoon it was just an publishing framework. My project was a database oriented project and I choosed Cocoon as my flagship to do the job done. Somepeople told me: "Looks this guy! Choosed an web publishing framework to build a database application! It must be crazy enough!" So I am now trying to see an RAD webapp framework in Cocoon. This is the next level for me. Here is where Druid and OJB go into the play. And this is why I am writing about Druid and OJB. Woody is just a piece of all the cake. Best Regards, Antonio Gallardo
