Indeed our split isn't perfect - so there's a list of things we can and cannot do - depending on which engine version is needed to support the changes - this forces a good process (because it forces thought on it).
The submodule link is a version dependence - it's just hard to think of it like that because we go engine->ide, rather than ide->engine which would be 'better'. Of course I use the term A/B testing - but that's just a superset of what we are already doing (we're just doing one test at a time at the moment and probably will do for quite a while). However, the underlying process should be the same - and the points of friction are actually also points of potential error (in terms of if the boundaries weren't there then it would be where we could be more likely to make a mistake) - so those points of friction help maintain good process (because it forces us to think about the dependencies). A lot of the IDE first run things are just superficial in the sense they are entirely ide code, and engine tweaks are generally fixes which have to follow maintenance procedure anyway. And yes, submodule a cause grumblings internally and from contributors - so that just requires tooling to help, and a gradual cleanup of the boundaries of our repos so we can eventually restructure slightly to serve us better until they aren't a problem anymore. Retaining our quality process is higher priority I think, and should come first right now - that's all. Warmest Regards, Mark. Sent from my iPhone > On 30 Jul 2017, at 23:17, Monte Goulding via use-livecode > <use-livecode@lists.runrev.com> wrote: > > >>> On 31 Jul 2017, at 6:59 am, Mark Wieder via use-livecode >>> <use-livecode@lists.runrev.com> wrote: >>> >>> >>> Actually, submodules actually do their job really quite well. They aren't >>> ideal, but they do enforce modularity (hence the name ;)). We just need to >>> get round to sorting out some tooling (local shell scripts / git hooks) to >>> help make sure they aren't quite so easy to forget about syncing properly. >> >> It's possible (and IMO preferable) to have a modular approach to app >> building in makefiles and such without forcing git to have to deal with that. > > Submodules are very helpful when they are doing what they are meant to do > which is point to a specific version of a dependency. > > Unfortunately with the ide submodule we have two way dependencies and tests > that break in one or the other or both if they aren’t updated in sync. Indeed > we have some ide libraries in the engine repository. So sometimes to make a > seemingly small patch you need to patch both repos. Additionally it’s easy to > break an IDE test and not find out about it until everything is merged up > because tests are run against the main repo (this is potentially solvable by > working out how to run the tests for all the submodules but it will require > some special Travis wrangling). > > There is an overhead to all this that I personally believe doesn’t justify > the benefits. Should we have IDE A/B test versions then I think we will need > to branch the engine repo for them sometimes anyway so any benefits may be > less than they at first appear… indeed the scenario may multiply the > overheads… > > Anyway, probably better to continue this discussion internally as not may > people here would be interested in this. > > Cheers > > Monte > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
