On Sun, Mar 7, 2010 at 11:49 AM, David A. Bandel wrote:
> On Sat, Mar 6, 2010 at 13:56, Luke wrote:
>
>>
>> Can the codebase be moved to PHP while you're at it?;-) (A guy can dream,
>> even if unrealistically)
>>
>
> I would hope this would never happen. I have strings of horror
> stories relat
On Sat, Mar 6, 2010 at 13:56, Luke wrote:
>
> Can the codebase be moved to PHP while you're at it?;-) (A guy can dream,
> even if unrealistically)
>
I would hope this would never happen. I have strings of horror
stories related to PHP and do not and will not ever install this
security disaster
I'm not sure I follow the logic behind this.
Wouldn't it be more reasonable to start 2.0 development immediately after
1.3 stable release? Trying to make it work within or over the 1.3
codebase seems like more work, with minimum reward, since alphas of 2.0
will effectively do the same thing, a
On Sat, 6 Mar 2010, Chris Travers wrote:
> Correct. AR/AP transactions would be what would be standard out of
> the box under this proposal.
[.]
>> Some sort of simplified service invoice would have to be included,
>> overrideable by a full invoice with the inventory package.
>
> AR/AP transactio
One more interesting idea
I wonder if it would be helpful to make the core framework for 2.0
into an addon for 1.3?
This would allow us to:
1) Build the core framework (requiring Pg 8.4 for that) as an
alternative for addon-developers.
2) Rebuild the core financial logic on framework
3
On Sat, Mar 6, 2010 at 10:56 AM, Luke wrote:
>
> For what it's worth, I, big surprise, support this.
>
> I am more of a user than a developer right now, but this would make the
> development door a bit easier to pass through, I should think.
>
> Can the codebase be moved to PHP while you're at it
On Sat, 6 Mar 2010, Chris Travers wrote:
> The basic approach I would like to push is that of "kernalization," or
> of essentially creating a smaller project with more optional addons.
> There is no reason for a financial services business to have inventory
> control, and multiple types of POS mod
Hi all;
Looking at this, I would like to suggest that after 1.3, we just begin
work LedgerSMB 2.0. I would like to make a set of concrete proposals
regarding this development.
The basic approach I would like to push is that of "kernalization," or
of essentially creating a smaller project with m
