[erlang-questions] how do you build your releases with/without rebar?

[Mahesh Paolini-Subramanya]

This is as much a discussion of Methodology(tm) as of anything else - as with
all things Methodology(tm), there are two over-riding rules
1) Any Methodology(tm) can be made to work (*)
2) All Methodology(tm) fail at the edge.

The sad truth about most projects is that - if they survive long enough -
they *will* hit the edge, and modifications to the methodology *will* be
necessary.
There is any amount of literature out there about this, but it all boils
down to the issue of "communication overhead" vs "process".  Basically, the
more people / components / resources that a project has, the more work
involved in co-ordinating all of this, and eventually the co-ordination
overhead gets so huge that nothing ever gets Done.
Enter "process", which reduces efficiency, but also the communication
overhead, thus increasing the likelihood of something getting Done.  (**)

The bottom line is that apps/*, (libs, relx, rebar, erlang.mk, git,
"drunken stumble", whatever) may or may not be the panacea for what you are
trying to accomplish, it really, *really* depends on the specifics of your
situation.  If your field-of-vision gets wide enough, you'll end up finding
issues with pretty much anything that you try.
But then again, to paraphrase Keynes, "In the long run, everything fails".
 This doesn't mean we shouldn't try to accomplish anything, it is just one
more indication that discussions like these are very helpful in exposing
   - Which systems are out there
   - Who is using a particular system
   - What the rationale behind these systems is
   - Why certain systems work, and other systems don't for some
   - How to go about implementing any particular Methodology(tm)
   - Where to look to get help
   - (And most importantly) When to change the Methodology(tm)

About the only certainty in all of this is that one shouldn't trust
Purists.  If anyone starts advocating The One True Way, run in the opposite
direction - preferably with your hand on your wallet...

*  -1- can end up involving godzilla-sized vats of elbow-grease
** There is a long rant about this
here<http://dieswaytoofast.blogspot.co.uk/2011/12/process-breeds-process.html>,
which was written in a different time and place, but the core points
are
fairly valid, viz., small groups, loose-coupling, co-ordination, and
flexible mindsets. And yes, erlang helps.

On Sat, Apr 12, 2014 at 4:59 PM, Loïc Hoguin <essen@REDACTED> wrote:

>
> You need to coordinate changes, yes. But it's much easier to do it if the
> repositories are separate. Because you can start by changing private_key
> and then release a new version of that. OTP itself still uses the previous
> version so nothing breaks. Then you can change ssl and release a new
> version of that. Similarly, OTP doesn't break. So on and so forth until all
> the applications are updated. Then you can think of bumping the versions
> used by the OTP release, and you can bump all at once and only then make
> sure it still works with everything else. The big difference here is that
> you didn't need to worry about "the rest of OTP" while you were making the
> changes, only at the very end. So you can focus on implementing the new
> feature and nothing else until it time comes to bump the versions used by
> OTP.
>
> Anyway I get your points, and hopefully one day someone will take a
> serious look at the apps/* layout and make something beautiful.
>
>
> --
> Loïc Hoguin
> http://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 

* Mahesh Paolini-Subramanya
<http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png> That
tall bald Indian guy..*
* Google+ <https://plus.google.com/u/0/108074935470209044442/posts>  | Blog
<http://dieswaytoofast.blogspot.com/>   | Twitter
<https://twitter.com/dieswaytoofast>  | LinkedIn
<http://www.linkedin.com/in/dieswaytoofast> *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140413/12d8dff5/attachment.htm>