On Tue, Nov 24, 2009 at 3:29 PM, Zishan Mirza <[email protected]> wrote: > 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. > I agree on that one though I think this check needs to be more generic. It should check whatever repo it is configured for the latest version of any given package when it is asked to upgrade or install the latest.
> 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. This it has, I think we just need to make it more clear and I think it needs to use the Erlang version not the Erts version. > > 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. Agreed. I think we should add a nice commandline interface on top of it. When you type faxien installed there should be an asterix or something next to any pinned versions. We should make it easy to add and remove pins from the command line. > > 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. We already have that with the translate version (or something like that) function in faxien. 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. I think faxien should accept both, but I don't think an option is required. the versions are different enough that we can easily detect them. If it has an R in it it must surely be an 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. I think we can just check for the R. Basically, Faxien could check the Erlware > repository and get the ERTS version and map it to the Erlang version. This I don't like. Becuase I want this all to work well for non Erlware repos as well. Many people have their own private repos. > > 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. > > > -- 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.
