Sure, I'm free at 2pm. On 30 Nov, 00:06, Martin Logan <[email protected]> wrote: > On Sat, Nov 28, 2009 at 4:45 PM, Zishan Mirza <[email protected]> > wrote: > > It appears that the starting point for this task would be in the > > fax_manage module, where it sets the preferred ERTS version. I think > > that it should accept both and I have a put an if statement to check > > whether the input it actually is an ERTS version, and write that to > > the config file. > > We should jump on a phone call to clarify this tomorrow. I am not sure > I fully understand this though the gist sounds right. I am free > tomorrow at 2 my time if you are. > > Right now, if you specify R13B, for example, it > > > overwrites it to where the erts version should be. Now, my question is > > that, should Faxien know which Erlang version each ERTS version > > corresponds to? It would be possible to write the Erlang version and > > the corresponding ERTS version as a tuple in the config file. > > This is done already in epkg.hrl. I agree though that this should be > moved from there to a config file. You should start with that .hrl > file and grep for the usage of that macro so you can get familiar with > what functionality has been put in place already. > > > > > > > On 27 Nov, 11:53, Zishan Mirza <[email protected]> wrote: > >> 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 -- 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 > > 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.
