No, I don't think it will be much more difficult than any of the other
upgrades.  It's all just little incremental steps.

And the changelog will explain any changes that need to be made. We'll
try at least!

Cheers,
Dan



On Thu, Dec 18, 2008 at 6:03 PM, Daisuke <[email protected]> wrote:
>
> I wonder if this version is going to be very difficult to upgrade from
> v2.x..?
>
> On Dec 19, 3:48 am, "The Editor" <[email protected]> wrote:
>> Ok, I'm thinking out loud again.  Here's my list for candidates for 3.xx
>>
>> 1). Change BOLTargs to simpler array output. It occurred to me, it
>> will be easy to fix compatibility issues in plugins. Just extended
>> search and replace of $args[''] -> $args. Only some plugins will work
>> on only one version or the other--we'll need to specify.
>>
>> 2). Simplify code so skins are installed the same way as plugins. This
>> should eliminate a lot of unnecessary and complex code. As well as
>> some problems when using add-on domains and cleanurls, etc.  This mean
>> all skins will have to be repackaged for installation.
>>
>> 3). Make the farm icon folder a plugin, and take it out of the core.
>> And since skins are now going to be plugins, we might as well just
>> have a single farm folder with all the plugin stuff...  Simpler is
>> better!
>>
>> 4). Rewrite file read/write functions to allow for a central, custom
>> backend hook, such as for a database page storage system.
>>
>> 5). Add installation messages/descriptions to plugins, in backup
>> files. Probably will make a data value on the site.plugins.whatever
>> page. Easily retrievable into the plugins completion page. This could
>> include version numbers perhaps for the .backups.  Php files could
>> define their own version numbers. We just need to set a convention.
>>
>> 6). Add basic core function for accessing database info, and a command
>> to be able to write to a database. Multiple databases even.
>>
>> 7) Change all BoltWire classes to names that begin with Bolt, like
>> BoltSmall and BoltPreview.
>>
>> 8) Move site.cron, site.languages, & site.actions to site.public
>> hierarchy, or to a public directory. This would be the place for all
>> publically readable but not editable info/data.
>>
>> 9) Is anyone using BoltWire's cron?  I'm wondering if perhaps it
>> should not be moved to a plugin--as standard cron is so easy to setup
>> (on my server) and is preferable. And you know I'm all for keeping the
>> core lean and mean. It might be better to just have a way for admins
>> to setup their own background functions directly. Pseudo cron being
>> just one option. And I'm wondering if we shouldn't rework caching, so
>> it runs these background functions even when returning a cached page.
>>
>> 10) Just wondering if we shouldn't separate boltwire into two
>> downloads--one the code barn (which gets updated frequently), and the
>> other the field and farm folders (which would be mostly empty, and
>> only need to be installed the first time). It would make thinks easier
>> all the way around, except for the very first install, would have to
>> extract 2 zips.
>>
>> Feedback welcome...
>>
>> Cheers,
>> Dan
>>
>> P.S. Vacation is fun!
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to