I have some possible solutions to these issues. 1. When Faxien does an automatic upgrade, it should check the official Erlware repository for the latest ERTS version, get that version, and then do the automatic upgrade.
2. Faxien should have a way to set a limit that it should not install applications/releases beyond a certain ERTS version. It could be written down in a config file, for which Faxien could read it every time it installs an application or release. 3. There should be a config file where it should be possible to specify the application/release and which version of the application/ release should be pinned. Every time faxien upgrades, it should look at the file and get the version which the application/release is pinned at, and not upgrade it beyond that version. 4. A quick fix for this issue would be to create a function that prints out the ERTS version and which Erlang version it corresponds to. However, this is a bad fix. A much better way would be to create an option of either choosing to specify the ERTS version, or the Erlang version. Faxien should be able to accept both options and could possibly have a config file that states to what Erlang version or ERTS version it should stay on. The format of the Erlang version could be RNNB-N, where N are numbers. However, if this format will be used, then there should be some exceptions to this format, for example, for the Erlang version R13B02-1. Basically, Faxien could check the Erlware repository and get the ERTS version and map it to the Erlang version. I am still thinking about these. Let me know what you think. Zishan On 24 Nov, 21:31, Martin Logan <[email protected]> wrote: > Faxien has issues with the way in which it manages ERTS versions. The > first issue I think is that it manages ERTS versions. I think the > external interface needs to be Erlang versions and that we need to hid > ERTS versions from people to a great extent. What this email contains > are a number of issues and use cases where the current management is a > problem. > > 1. Download the bootstrapper and the automatic upgrade of Faxien does > not give you the latest version only the latest version for the ERTS > versions that the bootstrapper can see. This results in multiple > upgrades being required to get to the latest version. > > 2. Company X states that Erlang version R12B-5 is the standard for the > company. Employee X runs faxien ia <some-app-or-release> and gets a > package for the latest greatest that faxien knows about which is for > Erlang version R13B02-1 > > 3. Company X states that sinan-.0.11.2.3 is the defacto standard build > system version. Users have no way of pinning that version and > preventing an accidental upgrade. > > 4. Company X wants to stay on the R12B-X line in general. They can > now specify a range but it is confusing becuase they must use Erts > Versions and can't use Erlang versions. > > There are probably other use cases that exist around managing packages > and versions that we need to think about. Any more ideas are welcome. > Zishan and I, and anyone else that wants to join are going to start > iterating on this problem once we come up with a design. > > Cheers, > Martin -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
