On Tue, 14 May 2019, at 16:49, Thomas Cioppettini wrote: > Hmm this might be a nice side project. I think we could start with the > most common environments and build out from there. Based on some quick > research this may be more automatable than you may think. Based on what > I've seen most projects just are linking to the github archive and > hardcoding a hash of the contents. If that's it, then it should be > fairly reasonable to just update it. I'll do some more research and get > back to you. > > On Monday, May 13, 2019 at 2:35:20 AM UTC-4, José Valim wrote: > > Hi Thomas, > > > > It is not possible for us to handle all of the different OSes and package > > managers, manage permissions, debug errors, etc. Publishing is only one > > part of the process. > > > > However, we will be glad to improve our current "broadcast" infrastructure, > > so whenever we publish a new version, everyone can receive an event and > > have their automation tool publish to the OSes they consider common. Today > > you can get those events either via the google groups OR via the GitHub > > releases page (which provides a feed IIRC). > > > > *José Valim* > > www.plataformatec.com.br > > Skype: jv.ptec > > Founder and Director of R&D > > > > > > On Mon, May 13, 2019 at 6:39 AM Thomas Cioppettini <[email protected]> wrote: > >> I think we should manage the distribution of elixir to common package > >> managers after a release has been built. > >> > >> Right now we rely on other maintainers to be aware that elixir has been > >> updated, and do their respective work to add the most recent package to > >> their repository. This process is slow and unreliable, we should automate > >> it so that the most recent versions of libraries are available everywhere.
Hi Thomas, This is a desirable goal & I don't want to dissuade you, but this is a surprising amount of work, often requiring manual tweaking that requires a reasonably deep understanding of how packages and package managers work on a given system. <combinatorial explosion> The end result is that you begin to ship a custom OTP release, including static OpenSSL, and having your own per-OS custom package repos, to try to keep up. Then you find out that popular project X doesn't yet support that version of OTP, so now you ship multiple OTP releases per Elixir release. Phoenix, RabbitMQ, & CouchDB are well-known projects with varying bits of Elixir on the inside. </combinatorial explosion> That said, https://repology.org/project/elixir/versions may well be a useful place to start for somebody who is interested in hunting down what's lagging behind and submitting patches. Its source code is https://github.com/repology/repology & https://github.com/repology/repology-rules, and a neat hack would be, after X days after a release, to send a gentle reminder to the maintainers listed for any lagging downstream distros. Or, to post the list to elixirforums and recommend people contribute patches for their favourite distros. I think that having an announce@ list and encouraging maintainers to subscribe, is your biggest win for the least effort. It's certainly shortest in LoC :-) A+ Dave -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/4c9ba3af-59f6-4794-a681-f3035e34cca4%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
