This sounds good. I am now thinking on how to implement these. On 24 Nov, 22:50, Martin Logan <[email protected]> wrote: > 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 > > athttp://groups.google.com/group/erlware-dev?hl=en.- Dölj citerad text - > > - Visa citerad text -
-- 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.
