rebar3.git - Clone of https://github.com/erlang/rebar3

	Commit message (Collapse)	Author	Age	Files	Lines
*	large refactoring	Tristan Sloughter	2014-08-16	1	-219/+0
\| \| \| \| \| \| \| \|	Removed separate compilers Resolves apps to build Finds avail deps before pulling/building Includes relx Simplifies build commands
*	Fix OS X resource fork handling (Reported-by: Richard O'Keefe)	Tuncer Ayaz	2014-07-25	1	-1/+1
\| \| \| \| \| \| \| \| \|	If you happen to fetch a zip archive of the git repo and try to build from that, you may, for example, ask erlc to build src/._rebar.erl. ._* are OS X resource forks and not real .erl files. This may also happen with network filesystems on OS X. To fix that, limit the files compiled by rebar to include only those which start with a letter or a digit.
*	Allow specification of module dependencies for appups	Robert Newson	2013-09-20	1	-17/+26
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	The order in which modules, within an application, are loaded can be important. This patch adds allows the specification of module dependencies such that generate .appup/.relup scripts will load a module's dependent modules before itself. To use: in rebar.config, add a module_deps {module_deps, [{ModuleName, [DependentModuleName, ...]}]}. ModuleName is the name of any module, followed by a list of module names that it depends on.
*	Implement 'rebar help CMD1 CMD2' and extend common 'rebar help' msg	Tuncer Ayaz	2012-12-31	1	-0/+10
\| \| \| \| \|	* allow plugins to print help message for implemented commands * append core rebar.config options to common 'rebar help' message
*	Do not use application:set_env	Tuncer Ayaz	2012-07-23	1	-3/+4
\|
*	Remove shared state	Tuncer Ayaz	2012-07-13	1	-3/+3
\|
*	Fix whitespace errors	Tuncer Ayaz	2012-01-13	1	-1/+1
\|
*	get_reltool_release_info now expects consulted data	joewilliams	2011-07-12	1	-1/+1
\|
*	skip appup generation for new app in release	Andrew Gopienko	2011-07-11	1	-0/+2
\|
*	Merge pull request #90 from smarkets/upgrade-fixes	Joe Williams	2011-07-01	1	-8/+12
\|\ \| \| \| \|	look for new and old versions in the target parent
\| *	look for new and old versions in the target parent	Steven Gravell	2011-07-01	1	-8/+12
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	The target_dir config in reltool allows you to put your release in a directory other than in ./NAME, so we should look in the parent directory of that to find the new and old versions instead of simply looking in ./ Move untaring and retaring into a temporary path instead of in ./ to prevent name collisions with "releases" and "lib" that might exist already. Having a subdirectory rel/releases/ can be useful.
* \|	default module appup instruction -> load_module	Steven Gravell	2011-07-01	1	-1/+1
\|/
*	Apply Tidier suggestions	Tuncer Ayaz	2011-06-02	1	-11/+6
\|
*	Better org. of how upgraded apps are determined	joewilliams	2011-05-24	1	-16/+35
\| \| \| \| \| \|	get_apps/3 now returns which apps have been added, removed and ugpgraded in a reasonable way. It should prove more usable should we want to access any of those lists in future appup related changes.
*	Fix bug that causes appup generation to fail	joewilliams	2011-03-03	1	-19/+19
\| \| \| \| \| \| \| \| \|	This commit changes how rebar determines which apps have been updated, added and removed from a release during appup generation. Rather than use app files it now determines this from the rel file in each version of the release. In addition it fixes a bug reported on the mailing list when generating appups when an application has been added or removed from either release.
*	Ignore app files not in ebin	joewilliams	2011-02-25	1	-4/+4
\|
*	Clean up trailing whitespace	joewilliams	2011-02-17	1	-2/+2
\|
*	Clean up rebar_appups and rebar_upgrade	joewilliams	2011-02-17	1	-14/+8
\|
*	Fix generate-appups regression (atom vs list)	joewilliams	2011-02-16	1	-1/+1
\|
*	Add 'generate-appups' command	joewilliams	2011-02-15	1	-0/+185
	To further support OTP releases I have added support for generating application appup files. These include instructions that systools uses to generate a relup file which contains the low level instructions needed to perform a hot code upgrade. My goal with this module is to produce "good enough" appup files or at least a skeleton to help one get started with something more complex. If an appup file already exists for an application this command will not attempt to create a new one. Usage: $ rebar generate-appups previous_release=/path/to/old/version Generally this command will be run just before 'generate-upgrade'.