> 2) I see potential risks that you could crash a whole site if there is > some problem with the upgrade. I personally prefer manually overseeing > the process. Easier to fix things fast.
Looking at some IDE systems, I would recommend a system where a testing environment is automatically created, so the result of the upgrade can be previewed. I imagine the following steps: * An upgrade button is pressed The update is downloaded into the barns folder, where we have,say, the folder "barn-current" and the folder "barn-4.0.0" is added. * a link to the preview site is provided http://your.host.com/index.php?p=main&barn=4.0.0 with this link, the system uses the new barn and the site is previewed. To be completely secure a copy of the site pages/folders may be neccesary, but it's doable. Alternativly, one could simply disable the write-to-disk functions such that no changes are in the upgrade-preview mode are possible. * a button with "accept upgrade" is pressed. The older barn is deleted and the newer barn is renamed to barn- current. > > I think some kind of external installer script is the better > solution--probably not php. Though of course that installer script > could be called from within BoltWire. Anyone with programming > experience in a more appropriate language is welcome to tinker here. > I'd be happy to help where needed. > > The bigger reason is our upgrade process is sometimes a bit rough. If > we got to the point where we were really going from one stable jump to > another stable jump, this would make more sense. Maybe when we get to > 4.xx we can explore this some more. I really hope to slow or even stop > development of BoltWire at that point (esp BoltWire lite). So > occasional, more secure patches might be more appropriate for an > automatic upgrade process. > > Great suggestion, I'll file it away. When BoltWire is ready I'd like > to move that direction. > > Cheers, > Dan > > On Fri, Mar 12, 2010 at 8:44 AM, Erlend Sogge Heggen <[email protected]> > wrote: > > > My favorite feature in Wordpress is the upgrade functionality of both > > the core bundle as well as additional plugins. I know FTP overwriting > > is rather straight forward and possibly safer, but if there's any 'one > > button click' that I adore it's this one. > > > On Mar 7, 11:45 pm, The Editor <[email protected]> wrote: > >> We've been knocking out some good stuff lately, and there's only one > >> or two things left on my immediate agenda. So I took some time to > >> revise my roadmap for the immediate future. Here's an outline of > >> things to come: > > >> 1. Finish up the current 3.3.x series and put out a stable 3.4. > >> Basically, as soon as we feel confident the currently release seems to > >> be working. > > >> 2. Add a few things to the 3.4 series and finish it off with a final, > >> stable 3.5. And make this the end of the entire 3.xx round of > >> development. The todo's for 3.4 include: > > >> * Improved automatic paragraph making... We really need an entirely > >> different system for doing this... Have some ideas, but haven't > >> tinkered much with them yet. Soon... > >> * Improved performance of searching by caching index, and a new data > >> querying technique... I have a custom query script working on my site, > >> that gives impressive results speed wise, and with many enhanced > >> capabilities. I just need to integrate it into the core somehow. > > >> 3. For 4.xx I plan to finally do the major overhaul I've been planning > >> for how forms work. Namely, forcing all commands to be session > >> variables and allowing formats like this: > > >> [session mail to=... from=... subject=... body=... etc] > > >> These were listed as a 3.5 goal, but I've renumbered things, and it > >> seems more appropriate to make this a 4.xx goal, as it could be quite > >> disruptive, affecting virtually all existing sites and many plugins... > >> Yet I'm convinced this will be a major improvement to things. Can't > >> wait to do it... > > >> The other goal for 4.xx is to go through the code very carefully and > >> try to simplify everything possible: strip out all absolutely > >> unnecessary code. Features we don't use. Options we don't need. > >> Anything complicated. That kind of stuff. Just general house cleaning. > >> Perhaps even get us back down to under 100k. I've been beginning to > >> feel BoltWire is not quite as spry as it once was... > > >> To be honest, I'm inclined to have a BoltWire lite and a BoltWire pro. > >> With the lite version being a simpler feature set that is rock solid > >> stable, easy to use, and rarely updated. Just works. And then a > >> BoltWire pro that is more full featured, with a several choice plugins > >> built in, more actions and common stuff built in. Everything ready to > >> go as an all-in-one CMS system. Just toying with the idea actually. > >> Not sure I like maintaining two versions, but I like the idea of > >> giving people a really positive, first impression. And of having > >> something bigger with everything in it. Just thinking out loud. > > >> Well, open to feedback and opinions, and of course feature requests > >> not listed above. All the usual stuff. > > >> Thanks to everyone for being a part of BoltWire's development. > > >> Cheers, > >> Dan > > > -- > > You received this message because you are subscribed to the Google Groups > > "BoltWire" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/boltwire?hl=en. -- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
