Hi Chris, > Due to the length of time it took to get 1.3 out I haven't had the > time necessary to get 1.4 development going strong.
Although I do understand that you're doing the most of the development at this time (and have done so for quite some time), I believe we both agree that that's not the desired long-term situation. I'm saying this so that people reading this conversation feel invited to join the effort: it's not intentionally solely yours, is it? As I've said in private conversations over the past months as well: I'd like to contribute more as well, however, I'm unable to make commitments to specific efforts as far as commitments to specific release dates go. > Replacing the financial logic is going to be a big job. Agreed. Could we start working out a document which describes what should happen? That way, it would be easier for other people to join our effort: they'd simply have to read the document stating what we're doing and how far along the effort we've gone so far. > What I don't want to see is another 4 year release cycle. Absolutely agreed! > So I am going to suggest we shift our priorities and > don't tackle the financial logic yet. Thinking about this some more, I agree with you if you mean "don't start coding" by "don't tackle". However, I'm thinking we could start drawing up the impact assessment and plan-of-attack, the outline of the DB stored procs, triggers and what-not. If we create a good outline document with the mentioned components, I'm thinking it'll be easier for others to join the effort. And I think we want to make that as easy as possible: it'll be good for the community if/when that happens. > 1.4 should include as part of core > 1) New recurring transactions logic based on the template transaction > addon in 1.3 As we discussed in our chat, this changes the way recurring transactions are being posted; instead of copying a posted document, the process will copy a valid (but not posted) accounting/invoice document. The effect is that users will be able to schedule invoices without being required to actually post one first. Even more, it allows one to change all future invoices - which isn't currently possible. > 2) New trial balance module based on the enhanced_tb addon (currently > under testing for 1.3) You tell me this module is much faster and more flexible, such as allowing subsets of accounts to be selected. If we integrate the change you mention under (3) - allowing account totals to be split by the various classifications (departments, funds, etc) - that would absolutely rock! > 3) Generalizing projects, departments, funds, etc. out for reporting > purposes. Making these hierarchical Having hierarchical classifications as well as flexible classifications sounds really good; can we take into account that people may want to define multiple hierarchies for one specific class? (i.e. two or three department hierarchies. Sounds ridiculous, but it works great in practice.) > 4) Refactoring contact logic, making it more flexible, ensuring that > customers and vendors can be tracked as individuals instead of just > companies. Personally, I'd assign a higher priority to developing (web)services APIs than prioritizing this item. I'm not against this and definitely see the value added as well. We do have use for this, but we're just creating people as companies and setting them up as their own contacts. It works well enough for now. > Some of the work I have done on number/date formatting for 1.4 will be > included and this will allow a wider range of number/date formats to > be supported. > The goal would be to have something we could target for release in > summer/fall, and get our release schedule back on track, as well as > providing a basic springboard for further development into the > financial logic of the software. As I have expressed in earlier conversations (possibly private only?) I think that's a great idea: having a dependable release cycle where the functionalities which are done get released to the public. That way, the part of the community which benefits from those changes doesn't have to wait for some huge project to complete. My idea for approaching the financial logic refactoring would be to determine in the assessment which bits can be done on trunk as part of any release. That'll help paving the way for 'the big change'. When we're done refactoring the smaller bits, we move the main refactoring to a branch where we work on it at our own pace. There, the work isn't blocking releases of other functionality or fixes. Working on a branch until we're ready to integrate means we won't be forced to have another 4-year release cycle. > If I have time I would be open to putting some time towards an appointment > module, I would like to do that but at this point, there are no guarantees. > What do people think? Well, if you get funding for the appointment module, I'm the last one to tell you to earn money :-) However, if I look at the current structure of the application, I'm not sure where it fits in. I mean, other CRM software integrates with e-mail clients and agendas these days. Is an appointment module good enough? Bye, Erik. ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
