Next major release

[tsloughter]

I'd like to consider a major release, 4.0, and am opening this to discuss potential changes that will then be turned into their own issues to be worked on.

The first changes I'd like to do that break compatibility are some new defaults:

• extended_start_script: new default true
• sys_config/sys_config_src and vm_args/vm_args_src: I think these should be picked up automatically from config/sys.config[.src] and config/vm.args[.src] if those files exist or the config entries are defined.

I use dev_mode less and less these days since rebar3 shell has improved a lot, so I am less sure these are necessary but they are worth considering:

• dev_mode: new default true
• include_erts: either default false or have it be based on dev_mode

The point of these changes I'm trying to make is to simplify the base configuration most users would have. Today almost all I see have these values set exactly the same.

---

With a similar intent of simplification I think the next release should consider renaming the boot script to start.boot. This is described in a jira issue I opened, https://bugs.erlang.org/browse/ERL-859, but basically the issue is that the release created in the rel/ directory and a release tarball have different names for the .boot file. The former being <relname>.boot and latter being start.boot. This can be confusing and Elixir 1.9's release support simply renames to start.boot.

---

Another interesting thing mix release does is always create a tarball. It is minimal overhead to create from a already generated release but may be a little tricky because of our dev_mode. But something to consider doing and removing.

---

Adding prod_mode. This doesn't require a major release. The setting would enable a number of common settings that are usually listed manually, {debug_info, strip}, {include_src, false}, {include_erts, true}, {dev_mode, false}.

---

Last for now is removing the goal/constraint solver. This gives the ability for relx to act as the tool that does dependency resolution on constraints and chooses from multiple available versions of an application. But since relx is, as far as I know, always used on a project that has already resolved deps and gives it a list of the exact application versions to include, it is not needed and only adds complexity and confusion. This is one I guess we should verify no one uses but even if someone does we likely should drop it as they have other options for this (rebar3) today.

---

Edit: Just realized another potential improvement is removing the use of systools:make_tar. I did a quick profile of a rebar3 tar and the top time sink looks to be zlib deflating. This is done because relx first calls systools:make_tar, it then unpacks that tarball to add additional files defined in the overlays.

Building the tarball directly in one go, instead of having to compress twice, should save us a good bit of time, but it should be verified first.

Edit: Scratch that last part, I think I might be able to convert some of the custom shit we do to the tarball into options for systools. Then we'd not need to unpack/repack but can still just call systools:make_tar.

[ferd]

I would probably suggest going for a kind of mode setting with values like dev | prod | embed that impacts defaults: dev is just the quick symlinked release, no tarball, debug_info is in, neither src nor erts is in. Prod is a portable self-contained tarball (and release). It carries its own erts, src, debug_info. Embed is the fully stripped one, but has to include erts and libs as well.

Each option specifies what the 'mode' selects otherwise. I would default to prod. One reason is that dev mode is often broken on windows, due to symlinks. Not sure if it is still the case.

[tsloughter]

Good point, I like that. Only issue is embed is such an overloaded term and may be confusing. It may be fine and I can't think of a better word right now but is something to consider.

[ferd]

any other term like compact or minimal could make sense too I guess. The idea is to provide the smallest possible release that is portable.

[peerst]

Wish: Removing obstacles of including relx in OTP which then makes it easier to include rebar3 in OTP

[tsloughter]

@peerst yea, there is a lot of overlapping functionality between rebar3 and relx. It likely makes the most sense to add release functionality from relx directly into rebar3 and remove the dependency all together.

There needs to be a discussion with the OTP team about the future of reltool and if replacing reltool requires having a stand alone tool like it or if it being in rebar3 is acceptable.

[saleyn]

I'd like to suggest for the {include_src, boolean()} option when false to exclude source/doc files from all the apps included in the release (including those that are part of the OTP). As far as I understand presently it only excludes the sources of the apps in the project, but the ones from the OTP are still included with their sources.

Additionally, I find that it would be nice to expand the system_libs option to be: {system_libs, boolean() | [Path::string()] | AppNames::[atom()|{atom(), none|load}] | all}. AppNames would be a list of OTP applications that would not be included in the release package but for which there would be their paths added to the release's script file (e.g. {path,["$ROOT/lib/crypto-4.5/ebin"]}), so that the release can be booted using the applications already pre-installed on the local machine. The all option will add paths for all installed OTP apps that come with the distribution.

I believe this is in line with what @ferd suggested for the smallest possible release.

[tsloughter]

@saleyn hm, I thought it did exclude source from all apps... I'll have to verify in a bit.

[tsloughter]

Another change I plan to make: enable xref during release creation by default.

Specifically the exref arg systools takes to do the checks.

[saleyn]

@tsloughter, to verify I did rebar3 new app, added a release section with a couple of OTP apps, added {include_src, false}, and ran rebar3 as prod tar, which produced a tarball containing the OTP app sources despite the explicit include_src setting. So I wasn't sure if it was a bug or {include_src, false} was only meant to exclude sources of the apps included in the project tree.

[tsloughter]

@saleyn thanks, this is a bug then.

[tsloughter]

I was reminded of another idea from a discussion on elixir slack just now.

Because the releases built to rel/<relname>/ can not be used to build upgrades off each other (since you need to first do a tar to have systools:make_tar create a release in the right format for release_handler to understand for upgrades) there is really not a good reason to keep all of the versions under rel/<relname> and we may want to split it like rel/<relname>-<vsn>/ or rel/<relname>/<vsn>/.