That sounds along where I was thinking myself. My feeling in terms of numbering is that for the most part once a minor (1.5, 1.6) release is pushed out (ie. 1.5.0 released as such) we should be very cautious about any new or changed features in the release. While deciding *which* features end up in a particular release, I think the release schedule should be "organic" unlike it seems major companies who really like to make major changes on a regular schedule. Thank you for the clarification. Jigme Datse Yli-Rasku On 2016-10-17 20:03, David G wrote: > Hi Jigme, > > > On 18/10/16 10:38, Jigme Datse Yli-Rasku wrote: >> 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. > Just a note regarding 1.5 vs 1.6 for merging Multi Currency. > At this time, there is no plan to merge it into 1.5. > The migration strategy is not something that is going to be resolved in > a couple of days, or even a couple of weeks. > Unfortunately it's a complex issue due to a variety of reasons, > including the fact that only the "result" of certain FX transactions is > currently retained in the database, so the original data may not be > available in the DB to assist with the migration. > > The current thought would be to merge it into 1.6, then when we believe > there is adequate migration coverage, and 1.6 can be made otherwise > "ready for release" we would release 1.6 as the "Multi Currency release" > This would also include whatever other fixes and enhancements have been > added during that cycle. > > This is a slight change in release strategy from the past, in that we > are not saying that we need lots of changes before bumping the minor > number (1.5 > 1.6), but rather do so when a significant feature has been > added (ie: a feature milestone) > >> This is of course just personal thoughts. >> >> Jigme Datse Yli-Rasku >> > Regards > David G > > ------------------------------------------------------------------------------ > 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 > -- 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