On 2016-10-17 17:52, David G wrote: > Hi Erik, > > > On 18/10/16 05:29, Erik Huelsmann wrote: >> >> >> On Mon, Oct 17, 2016 at 8:51 PM, Yves Lavoie <..hidden.. >> <mailto:..hidden..>> wrote: >> >> Hi, >> >> I'm in favor of this. >> >> 1- The MC should be part of LedgerSMB, not something we promote >> only on a need basis. >> 2- It would get pulled in the distribution stream, contributing to >> marketing of our work. Having apt for the standard and GitHub for >> MC isn't appealing to users. >> 3- We are very few, so removing burdens and freeing time to >> develop quicker should be the goal every time. >> >> >> It's great to see that is isn't meeting much resistence. However, what >> about the (for now) missing data migration? It could end up being a >> blocking problem to release 1.6. Do you see that as (accepted) >> collateral damage? >> > As you mentioned, I feel that if we merge Multi Currency (MC) branch > early rather than late in the 1.6 lifecycle the burden, and likely hood > of it being a blocking issue, should be relatively low. > We already discussed the following benefits. > > * There are currently a relatively small number of systems (and likely > a small to moderate number of transactions) that will be effected by > migration issues. > * There will be an increasing number of systems and transactions that > will be effected the longer we wait. > * If we start any sort of marketing push, the number of effected > systems will hopefully grow exponentially > * Merging early allows all of the changes to receive much desired > exposure to both real world and contrived testing over a long period > of time. > * Most (probably all) devs will be able to continue with development > and testing without needing to deal with migration of data on day one. > This is due to the fact that migration will only be needed for > specific FX transactions > * If we ensure that affected (un-handled) FX transactions found during > a DB upgrade throw as errors and block the upgrade, the dev can > discuss on #ledgersmb > <https://riot.im/app/#/room/#ledgersmb:matrix.org> and we can work > out ways of migrating data transaction by transaction. > This should > o spread the burden over a period of time > o Allow us to handle actual scenarios, rather than trying to > predict *every* scenario > > If on the other hand we wait until later in the 1.6 life-cycle, we have > a requirement for > > * additional burden on the dev's (primarily Erik) to maintain the > merge synchronization of the MC branch > * a concentrated burst of testing and validation when the merge happens > * a need to rapidly resolve the migration issue rather than doing so > over a longer period of time > >>> Two weeks ago, when he was in Europe, David sat down with me to >>> discuss a number of items. Some of those will come later. There >>> was one major issue we discussed though and I want to bring our >>> proposal forward here. >>> >>> David put forward that having the MC (multi-currency) branch >>> merged to master gets a maintenance burden off my shoulders >>> (which it indeed will). In addition to that, merging to master >>> early provides for a (hopefully) long enough period to shake out >>> any of the problems that it may cause. >>> >>> Additionally, his idea is that if this code is on master, it >>> becomes our collective problem to create a data migration >>> strategy to MC, whereas currently it's probably mostly my problem... >>> >>> While I'm not very much in favor of throwing up roadblocks for >>> releases, even if they're far in the future. However, I must >>> admit that if there are others in favor of moving MC to master so >>> we have it for 1.6, getting rid of the maintenance burden >>> (however small) does seem attractive. I thought that I would put a bit of what my thoughts on this are. I do very few transactions during a month. I very rarely will be doing multiple ones which will have foreign exchange on them, so figured I had no real reason for using the MC branch myself. On a recent transaction which I completed, I found that I was having different exchange rates being expressed in different places, on the same day (on the same transaction) which meant that even though the transaction all took place on the same day (and pretty close to at the same time at all locations) I ended up where I was using multiple exchange rates on the same day. This is *not* allowed in the non MC branch. So you either need to "unify" your rates, or you need to fudge your dates. Neither of which really express reality. Which means that while the books might "work" (and you can make a note to explain why they are recorded as such) they are not self evident why they might be technically incorrect. I personally feel that it probably is rare for any business to strictly do business in a single currency. An issue I "discovered" while I was working on this, was the presence of fractional cent values being stored (and displayed) in foreign exchange transactions. When I looked at the github issues, there was an open issue expressing the exact same experience. The question as to *when* would be the best time to merge the MC branch(s) with the "master" of the version I'm not sure when is the best time. I would say "sooner is preferable" personally, but we are currently developing on 3 different version 1.4 (I understand at this point pretty much bug fixes) 1.5 (currently as a RC (unless I missed something)) and 1.6 (in very early development, not quite sure what to call it). I have seen evidence of development back to 1.3, and possibly even 1.2 in recent months, but my understanding about that is it is being done because of some client of either Chris, or Erik still running those versions, so those releases are based on merging work for specific clients onto those versions (where doing so is pretty much a bug fix). My feeling about 1.5 vs. 1.6 is that if doing the transition in 1.5 does not end up meaning that releasing 1.5 gets pushed back more than a few days (maybe a week) then I say we could well do it there. We are so close to releasing 1.5 as it is, that doing anything which pushes it back much at all I feel is somewhat problematic in my view. This is of course just personal thoughts. Jigme Datse Yli-Rasku -- Jigme Datse Yli-Rasku ..hidden.. (Preferred address for new messages) 250-505-6117 Jigme Datse Yli-Rasku PO Box 270 Rossland, BC V0G 1Y0 Canada ....................................................................... ... This message should be electronically signed, and if the sender ... ... has your public key, may also be encrypted. ... ... If you have any questions about this, please email, or call. ... ... ... ... Note, unknown calls likely will go to voicemail. ... ... Please leave a message if you get voicemail. ... .......................................................................
Attachment:
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel