On Apr 6, 2008, at 9:44 PM, Squirrel wrote: > On Sun, Apr 6, 2008 at 2:03 PM, Vincent Massol <[EMAIL PROTECTED]> > wrote: > >> Hi Squirrel, >> >> If it were that simple! There's no silver bullet unfortunately. >> Adding >> stuff that suddenly makes the application faster, better, etc with no >> change to the application is very rare... :) >> Or maybe I missed what you were saying? > > > Well, I didn't mean no change to the application, I mean no bigger > changes > which would force the user to do some changes too. Ie. if you change > some > tables or changes new things / features who would break the > customization > the user did to the skin ie.. It's only general speaking, but as a > user I > don't want any surprises ;-)
Sure, I don't think anyone would disagree with this. Re the database we have automated upgrades exactly for this purpose. As a user you don't have to do anything (unless we missed something and there's a bug of course). > That's an interesting statement that requires more input: >> >> 1) Why do you need to upgrade? >> 2) Why is hard to upgrade? > > > 1) If something is new you can bet your a..money that the user want > it. Right so you agree that faster release cycles are better as otherwise that means no new stuff for a very long time ;) > Beside often there are improvements which the user drools over. > Sometimes > they are security updates so you should update (I'm speaking now > generally) > > 2) I'm coming from the Joomla! crowd and for me it was a lot easier to > update my Joomla installation than the Xwiki. Also the installation > itself > was way more straight forward (ie. the config file was set up during > the > installation and stable even after updates). Nevertheless, I'm now a > Xwiki > user ;-) What do you find hard to upgrade xwiki? We can certainly improve but it's pretty straightforward right now: you replace your current WAR with the new one and off you go... (apart from keeping your xwiki.cfg and hibernate.cfg.xml files). Re the 2 config files, I'd also like to move them out of the WAR so that upgrading the WAR doesn't involve saving them and restoring them. I'm currently working on the new configuration component that'll allow this. >> Re the stable/branch/etc that's exactly what we do... :) >> We have the milestones/RC that last for about 3-4 months so we only >> release a new version every 3-4 months. We can hardly call this >> quick! >> Moreover you should know that the longer a release the less stable it >> is in general since there are more stuff in it. From a user point of >> view the best is to get the shortest possible release cycle. This is >> what ensures the best quality in general. The Hudson project for >> example releases every day or every 2 days and that's the greatest >> possible. I'd love that we be able to do that with XWiki and this is >> my personal target. >> >> Thanks for your feedback. >> -Vincent >> > > I'm coming from the Joomla/Drupal corner and therefore I'm more used > to > longer release cycles for bigger improvements. I have nothing against > frequent updates on the stable branch (security fixes, minor > improvements) > as long as they don't break things and somehow I have the feeling if > Xwiki > gets more attention from the general user side (not developers or > advanced > users) that could lead into trouble as users will start howling (but > right > now the entry barrier is too high for the average Joomla!-user, > IMHO). I'm > not so sure if it's indeed the best thing for the user to get daily > updates, Sure but it's not because there are updates that you *have* to upgrade... The user still decides when he upgrades. > in the labor this might work, but out in the wild there are maybe > way more > side-effects and they need time to pop-up... > > However, my statements are not really qualified, so I'm sure you > will do the > right thing and I hope you get my statements not wrong in anyway. :-) Not at all. Feedback is always good, thanks :) -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
