http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5872
--- Comment #19 from [email protected] 2011-05-05 05:05:32 UTC --- (In reply to comment #18) > Most people install from releases, not from git, so adding a submodule step in > the install is not tenable, it would have to be included in the tarball, or be > able to be installed another way easily. I didn't want ppl to do that. But I meant some clever developer could add that command in the command line script (Makefile.PL or into the make process)(before copying koha directory into the blib directory could have been a nice way). Of course, if one does not have internet access, git submodule update --init would fail. But if one doesnot have internet access, then it is nearly impossible to install koha. > > It is possible to do the update before the building the release, I will then > have to of course check the files havent changed in a way that breaks our > usage > of them, unless we pin to a specific version. > > Can you do that, pin the update to only grab a certain version, that way it > could be added before the release without as much danger. Otherwise we are > effectively including untested files in the release. (We use version numbers > for the perl modules we depend on, using the same for the js would make sense > to me). My experience of git-submodule is that when you commit your submodule addition, it stores the commit id of the project in your directory, so that when ppl do a git submodule update --init then it uses the commit id stored to synch with it. And not the latest version. See here what is described as a flaw would act in fact as a feature in our context : http://www.openembedded.org/index.php/MultipleRepositoryMethods When we want to upgrade for instance jquery version (for tests or for good) and are ready to do that, we could do a git submodule synch -- jquery And we could locally test the side effects or their absence. then git commit the directory when tested. In our workflow, that means no direct changes in those libs, at least at the moment, and hopefully for a long time, I think it is easier than the get the tarball unzip the tarball commit all the files... It is just a new command. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
