search

erlang / rebar3

Erlang build tool that makes it easy to compile and test Erlang applications and releases.
http://www.rebar3.org
Apache License 2.0
1.69k stars 515 forks source link

Promote the appup plugin to core component? #2103

Open ferd opened 5 years ago

ferd commented 5 years ago

https://github.com/lrascao/rebar3_appup_plugin

This plugin by @lrascao has been maintained for years, aligned with all the same requirements we have for rebar3 itself, and I've personally tried it a few times when working with relups and it functioned well.

I think that by now @lrascao has proven that he'd be reliable as a maintainer, no other plugins seem to have made a similar dent in the landscape. If he's open to it, it might be worth it for us to promote his plugin to be in core rebar3 functionality since it's appearing sustainable.

The license is compatible as well.

I haven't discussed it with anyone before, but this issue could be a good place to do so.

A few of the things I have concerns about:

Are we okay with the design and UI approach of the plugin? It seems to integrate tightly with a git or hg environment that assumes all branches and concurrent development takes place within one directory. I think however that the current relup command has the same limitation or behaviour, where it expects all the data in the same _build directory.

There are about 8 issues and 4 PRs currently open in the plugin. These are probably things we'd want to close before importing them, since if there's any API change expected, it would make sense to do it before we freeze the code within a guarantee of rebar3.

Are there other API changes that would be worth it in there? It makes sense to do them all before we pull things in.

Documentation would need to be added. I think this would represent work within a greater "how to structure your development to align well with hot code upgrades".

Other maintainers (see: @tsloughter) need to approve. @lrascao needs to provide approval as well. If he's not interested, we won't be bringing this in either.

lrascao commented 5 years ago

Regarding of what means to be a part of the core functionality, would the plugin then be a part of the rebar3 binary? This probably would not appeal to everyone

ferd commented 5 years ago

yeah essentially this would require taking the command and all the code, moving it to the rebar3 project, and then it would be standard command like relup or compile, though I guess it could be doable as a dep.

lrascao commented 5 years ago

i'm generally ok with this direction, but maybe a simpler (and cheaper) first step is just adding the plugin to the rebar application template or other forms of usage promotion, this allows to test the waters regarding adoption/acceptance while at the same time improving documentation and fixing issues

On Fri, Jun 7, 2019 at 1:04 PM Fred Hebert notifications@github.com wrote:

yeah essentially this would require taking the command and all the code, moving it to the rebar3 project, and then it would be standard command like relup or compile

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/erlang/rebar3/issues/2103?email_source=notifications&email_token=AAE4DN7IPMIXGOGWVMOHPKDPZJFFVA5CNFSM4HVEFVIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXFT75Q#issuecomment-499859446, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE4DN54RBHQWYHJXXBWFELPZJFFVANCNFSM4HVEFVIA .

-- PGP fingerprint: F708 E141 AE8D 2D38 E1BC DF3D 1719 3EA0 647D 7260

ferd commented 5 years ago

I think it's generally fine to provide commands even if not everyone will use them. For example, tree or xref might be used by a fraction of users. Mostly I see the appup plugin as a real nice step to fill the gap between release and relup, where otherwise everything must be backfilled by hand.

The one thing I'd like to figure out is how to encode the best practices to easy development cycles with hot code loading. For example, relup reorders things such that apply instructions always take place after upgrades, so if your upgrade requires something to be started or stopped by hand before it takes place, you kind of get in a weird spot. If you require a supervision tree to be restarted, that's an upgrade, but the cross-app ordering is not obvious to handle in such cases either.

So there's probably a way to cut up development and releases that would cater to that better, but I'm trying to figure out what it is that would make things simpler.