Hi guys,
I propose a short term schedule for Amber: - Keep the semantic as it is for now ( = no new pseudo variable for JS) *but* keep it in mind and open for discussion (I propose this because I'm still unsure about it :-) ) - Include the ImpCompiler from Herbert as soon as it will be ready, and keep the current compiler as the default one, at least for the time being - Improve the current compiler with the previously mentioned issues (I'm especially interested in variables scope, JS var name clashes and such things) - Improve the website (Got some news about it John?) - Move to ES5 with and possibly include a shim lib. - Keep pushing, fixing issues, adding tests and doc - release!! Nico |
What do you think about timeboxing ? I mean releasing every 4 months for example ?
Laurent
On Wed, May 9, 2012 at 11:57 PM, nicolas petton <[hidden email]> wrote: Hi guys, |
Hi all!
I am all for Nicolas list - keeping the issue tracker clean is a good priority, but I think at two "infrastructural" things would be nice to get some movement on: 1. Make deployment "trivial". Right now it is fairly trivial to get started with Amber I would say, with the one-click and all. But deployment still takes a few steps... For example, wouldn't it be way cool if one could press a button in the IDE and it would just put together a zip that gets downloaded with *all* inside - you just unpack it under Apache somewhere and bam, done. 2. Move forward with the package model. When I worked on that I got so far as having proper Package class and ability to keep and save meta data in them etc. But a simple working dependency model is of course the next step. I have a huge list of other cool things, but the above two may be the most "important". And well, improving the Debugger would also be way nice. Time boxing, sure. Works for me, but I think Nicolas should decide. regards, Göran |
In reply to this post by Nicolas Petton
nicolas petton wrote: > Hi guys, > > I propose a short term schedule for Amber: > > - Keep the semantic as it is for now ( = no new pseudo variable for JS) > *but* keep it in mind and open for discussion > (I propose this because I'm still unsure about it :-) ) > > - Include the ImpCompiler from Herbert as soon as it will be ready, and > keep the current compiler as the default one, at least for the time being It's stalled on the nameclash issue further compicated by inline JS element. If it would be possible to accept on of the proposals I have posted yesterday (or day before) subject "Variable names / inline JS:...", it would un-stall it. Otherwise, it's more or less ready and I would like to put it to hard test. One thing to this: I would like to have single point where the compiler could be switched... one possibility is to rename existing compiler to FunCompiler and create alias in boot.js - it is probably ok to have this point static, switching code generating in runtime is probably not needed. > - Improve the current compiler with the previously mentioned issues (I'm > especially interested in variables scope, JS var name clashes and such > things) > > - Improve the website (Got some news about it John?) > > - Move to ES5 with and possibly include a shim lib. > > - Keep pushing, fixing issues, adding tests and doc > > - release!! 1.0 or 0.9.2? You did not mention restructuring st.send mechanism, so I presume you see this as longer goal? > Nico |
Free forum by Nabble | Edit this page |