Date: Mon, 18 Apr 2022 18:24:30 +0000 From: "Dave Cottlehuber" <dch@skunkwerks.at> To: erlang <freebsd-erlang@freebsd.org> Cc: "Pat Maddox" <pat@patmaddox.com> Subject: Re: How to stay current with Elixir? Message-ID: <d7436932-c1dd-4440-abcf-b50b6e5f6d8f@www.fastmail.com> In-Reply-To: <ED1C07BD-F4C9-4E1B-BBB4-DD1EAB06CC5D@patmaddox.com> References: <ED1C07BD-F4C9-4E1B-BBB4-DD1EAB06CC5D@patmaddox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Apr 2022, at 04:23, Pat Maddox wrote: > Hi there, > > We are evaluating FreeBSD for deploying our Elixir applications. We te= nd=20 > to use the latest available Elixir release. > > I am just getting familiar with FreeBSD=E2=80=99s over all process. My=20 > understanding is that packages are in quarterly and latest branches. > > I noticed that when 1.12.3 was released, the elixir port was updated=20 > only a few weeks later, and was available via pkg install. That may be=20 > because it was released on Sep 30=20 > (https://cgit.freebsd.org/ports/commit/lang/elixir?h=3D2022Q2&id=3Dc8c= bc675c0dbc1c2e9e916ce4594a5d1e6387a57),=20 > the last day of the quarter. > > If I were to submit a patch to update elixir to 1.13.4, would it only = be=20 > available in main through the end of June, after which it would make i= t=20 > into quarterly? > > We likely prefer quarterly for most of our packages, but would want a=20 > current elixir. I=E2=80=99m wondering how we can best accomplish that = -=20 > whether it=E2=80=99s possible with pkg, or if we should consider using= asdf to=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d7436932-c1dd-4440-abcf-b50b6e5f6d8f>