Re: How to stay current with Elixir?

On Tue, 12 Apr 2022, at 04:23, Pat Maddox wrote:
> Hi there,
>
> We are evaluating FreeBSD for deploying our Elixir applications. We tend 
> to use the latest available Elixir release.
>
> I am just getting familiar with FreeBSD’s over all process. My 
> understanding is that packages are in quarterly and latest branches.
>
> I noticed that when 1.12.3 was released, the elixir port was updated 
> only a few weeks later, and was available via pkg install. That may be 
> because it was released on Sep 30 
> (https://cgit.freebsd.org/ports/commit/lang/elixir?h=2022Q2&id=c8cbc675c0dbc1c2e9e916ce4594a5d1e6387a57), 
> the last day of the quarter.
>
> If I were to submit a patch to update elixir to 1.13.4, would it only be 
> available in main through the end of June, after which it would make it 
> into quarterly?
>
> We likely prefer quarterly for most of our packages, but would want a 
> current elixir. I’m wondering how we can best accomplish that - 
> whether it’s possible with pkg, or if we should consider using asdf to 
> install erlang and elixir, or some other approach.

Welcome, Pat

TLDR any feedback from real world users is welcomed; I suggest you
try running /latest/ and see how you get on with that.

Running jailed elixir apps with jailed zfs datasets for permanent
storage is fantastic.

The ports are largely maintained by olgeni@ and dch@ (myself) when we
feel the need to scratch an itch. We've been working over the last few
years to keep things as current as possible, and I think we are about as
close as we can expect for a volunteer-driven project these days.

Personally, I tend to run /latest/ packages because if it doesn't work,
I feel the pain, and then will fix it :-).

The quarterly branches are generally only for security fixes, and for
OTP, this doesn't really make a significant difference. Patches can
go into quarterly at any point in time, but the expectation is of
stability, and security fixes only, including dependent ports.

lang/elixir itself is held back primarily by compatibility with other
ports, notably net/rabbitmq, which only recently gained Elixir 1.13.x
support and OTP24 compatibility - https://www.rabbitmq.com/which-erlang.html

That said, there is a simpler build approach available for for
net/rabbitmq which I might switch us to, it would make updates much
simpler, should remove the direct Elixir version compatibility,
and thus allow bumping lang/elixir more frequently.

I would *generally* not backport net/rabbitmq just so that we can have
a newer lang/elixir in quarterly - that's the opposite of the
expectations that quarterly implies, for ports in general.

lang/elixir-devel tracks latest OTP (i.e. it is hard wired to use
lang/erlang-runtime24 and soon lang/erlang-runtime25) which is important
to me because of all the JIT goodness that's come, and other scalability
and performance improvements.

It should be updated a few days after each release, assuming nothing
else is blocking my queue.

Almost all other Elixir or Erlang ports we have don't really need a
specific dependency, or use releases in such a way that this isn't
important. There are many ports that BEAM users would simply install
via rebar3 or mix these days.

Feel free to share more details or questions.

A+
Dave