“All these changes are devastating to your existing library of material.”
Kerem,
Once again, jumping to conclusions at this point is misleading to the community.
Brent
It is a fact that the recent G2 changes, specifically the color definitions and object placement methods made all existing books, tutorials, videos relating to these topics inaccurate. Prior to this, I recall Jay having to redo lots of videos during widget 1 to widget 2 transition. I’m not in the tutorial business but a casual observer. Jay and other affected parties can chime in to support your remark if I’m wrong.
The first version of my post was deleted. So was the second. Way too inflammatory for a Monday morning. 
Because I thought it’s possible composer is an internal thing so they can run it at the same time as storyboard and when the bugs are all worked out, then it becomes storyboard. Composer could just be an internal, temporary name that accidentally leaked.
I’m hoping for something like that.
Jay
Jay, I think, again I’m speculating and I know Brent will call me on it but I think its much more than that. As of 2147 even the samples started getting updated. Just open WidgetDemo and check it out for yourself. It is no longer using Storyboard but now Composer.
Not sure if more information was provided yet, but docs are live for a library named composer.
http://docs.coronalabs.com/daily/api/library/composer/index.html
Cat getting out of the bag early must have meant some overtime for Brent or someone else rushing these docs over the weekend. Thanks for sharing.
no mention of params in the main doc or the migration guide. Are they dropped? Hope not!!!
It looks like they could be replaced by setVariable/getVariable.
http://docs.coronalabs.com/daily/api/library/composer/setVariable.html
Thanks for the link, Max.
Kerem, they show composer.setVariable() and composer.getVariable() – maybe those take the place of params.
Says you can set a variable and then retrieve it from any other scene.
Jay
It looks like composer will also support params.
If the params option was specified when calling composer.gotoScene(), composer.showOverlay(), or composer.loadScene(), the same value will be passed to event.params so it can be accessed by [createScene][api.event.scene.createScene], [enterScene][api.event.scene.enterScene], and [willEnterScene][api.event.scene.willEnterScene] event listeners for the scene that is being loaded.
If the params option was omitted when calling said functions, the value of event.params will be nil.
http://docs.coronalabs.com/daily/api/event/scene/show/params.html
Great. Thanks for digging that up. I had seen the set & getVariable but params is whats in my code so less rework I suppose. Time will tell…
Brent, releasing incompatible stuff to the public without prior warning and documentation is not really a best practice and is a sure way to get customers “speculating” and feeling frustrated. I have also purchased JA’s video course and feel for him Can we get some much needed bug fixes now?
Well… I know why I am still using the last G1 daily build for my old and some new(!) projects.
Using anything but the latest build gets all your bug reports rejected summarily. I know why I am not submitting any bugs reports anymore
We respectfully asked that you not speculate on this and wait until we could provide you with the answers to your questions. Here is what I can tell you:
Composer is a -new- library that will live alongside Storyboard. Think of it as “Storyboard 2.0”, but because we are changing and improving things within it, we decided to provide a different migration path for you. With Widgets 2.0 and Graphics 2.0, we had to make breaking changes because of their close relation to the core API. Composer is somewhat different and it can live alongside other Corona libraries. Once we release it officially, your existing Storyboard code will continue to work, and developers can move to Composer if it makes sense for them. Internally, we intend to move to Composer in our samples, guides, new tutorials, etc.
Composer is a good thing. It’s giving us a chance to re-factor some outdated Storyboard code to make it more sustainable going forward. This will also allow us to more easily address bugs and add new features going forward.
This thread has gotten contentious to the point that we’re going to lock it. Please respect our request and refrain from speculating on this until it’s announced.
@atanas, regarding your point about bug reports: this is not our policy and we feel a need to clarify so. In fact, nothing has changed in regard to our bug submission policy, except that now we are requesting full and complete examples along with bug reports which show the bug occurring. Previously, users would too often submit a “main.lua” file with no supporting files, but the issue was caused by something in their “config.lua” or “build.settings” file. Determining this was not an efficient process, so we are now reasonably requesting that users submit zipped mini-projects along with bug reports so that we may easier determine the cause.
We have not been “rejecting bugs” that are not tested with the latest Daily Build. If you supply a build number, we will test with that build in addition to the latest Daily Build to check if the bug has already been fixed. In some cases, if you supply a bug report with an old, outdated build, or one that’s older than our public release build, we’ll ask that you test your code with the latest public build.
Regards,
Rob & Brent