v1.0 Check list

[tony]

Check list is at the wiki on https://github.com/addyosmani/aura/wiki/v1-Checklist for editing / history. Conversations / discussions at https://github.com/addyosmani/aura/issues/134.

I will keep this top issue synchronized with the wiki every day or so. Please refer to the above link to move/add/remove/update items. - tony

ETA

End of October

Legend

• todo => not started yet
• in-progress => started, but not completed yet
• done => completed

For launch

• Consolidate tickets and labels - If there are duplicate / stale tickets, at this juncture it's OK to leave a reference to a sibling / child ticket. If the ticket is stale let creator know they can reopen, we're cleaning.
• Code Documentation - Clean up, spell check, read out loud
• Wiki Documentation - for Aura history, patterns, resources, development guidelines, etc.
• Routing - Backbone router example #93. done #136 - tony
• Website - Website for Aura in progress #132
• Yeoman - support #108 - support for yeoman generation
• Publish to package managers - Publish Aura to Bower, Jam and Volo

High

Things that would be nice to have.

• Statefulness example Handling a model/collection that is to be fed into multiple widgets? #127 - Definitely want to see if we can have widgets using the same data set somehow. If we cannot make this in time I'll document patterns in-progress #127 - tony
• Docco - depends on how code is looking.

Not sure

these are things that may not be relevant, feel free to remove/delete

• npm package - Put aura on npm site?

For future release

Can be marked with a v1.1 or a v2.0, etc.

• move / add something here.

Interlocks

Any upstream libs that have integration points or breaking changes upcoming?

• Backbone - ongoing - Edge uses dispose for clean-up
• Yeoman - released - Yeoman is released, it would be nice to have a generator
• RequireJS - looking OK - no breaking updates
• jQuery - OK

Last check Oct 8, 2012

Other

Checklist inspired by Ubuntu's blueprint concept, Ubuntu's interlock, KDE feature plan.

[tony]

Above is a stub. Discussion can take place here / or edit on wiki directly.

We need to add / move / update issues. If an issue is respective to you just edit and drop a note.

Issues in this project can be cleaned now. It's common practice on other projects to close with a comment of "duplication"/"merging with similar discussion", "continued at..", if stale "cleaning up". Close telling OP if they want to continue just reopen. Thoughts on this?

[addyosmani]

I fully agree with the items you've listed as high. If we can find an owner for the docco work that would be great. I can help move the statefulness work further with reviews/input. I do think we should also add having a better app as a high item for 1.0.

This can either mean more widgets or a completely different app. I'm working on the concept of the latter at the moment, but am probably a week off having something I can show. If I get stalled its fairly straight-forward for us to go down the widget path.

[addyosmani]

Re: Backbone and dispose. I actually investigated this for a few hours and tried to figure out how we could easily pipe back through to it. It wasn't as straight-forward as I was expecting. Because we alias Backbone's various classes and rely on anonymous modules/AMD for each View/Model/Collection block, we can't access specific classes for cleanup using dispose. We don't store references to these things in any global namespace so, say, a lower-level piece like the mediator can't access individual views for disposal - we're only able to work on a DOM level to cleanup elements and events bound to them.

A solution to this would be using some sort of reference cache that keeps track of each Backbone class created (e.g instances of Views, Models and so on) which we can iterate through based on type then dispose, but that introduces (has to) a global namespace. Could be aura.cache or something if we really thought we needed it.

[PaulLeCam]

Hello,
I think a cache would be a great addition, I really like what the SoundCloud engineers described in this article, being able to load a Model from cache by calling its constructor is very simple and useful, it would be nice to have something like this in Aura !

[addyosmani]

Very interesting article. An instance cache looks more or less like what we
need.

[tony]

@addyosmani I have Thursday - Monday to work on Aura / JS projects. Since last week, how do you think we're doing with the demo / issues? What would be the important things to focus on?

[tony]

@addyosmani @sindresorhus @dustinboston @robertd @joelhooks btw are any of you ever around or near NYC? We will hack/sprint sometime.

[addyosmani]

@tony I'm based in London, but a remote hack/sprint would be awesome sometime :) I think at the moment the most important things for us to tackle are:

• Completing the work started by @rumpl in https://github.com/addyosmani/aura/pull/133
• Resolving https://github.com/addyosmani/aura/issues/100
• Figuring out the demo application we're going to use. Did you mention you were working on something you'd be able to share? :) I started a Facebook API client, but if theres something better I'm all for it!

[tony]

@addyosmani I may have something early next week. It's a production app/site using Aura and is a separate open source project. I intend to be PR'ing fixes and features upstream as it progresses.

Regarding facebook API: I'm intimate with it and have built a few apps with it, so if you want to double down on the Facebook API client, you can branch.

#100 / #133: Agreed on that.

[tony]

@addyosmani Are we looking to handle the features / api changes for #143 and #110 for 1.0? Since there are pretty big changes, I think it'd be best to have a concrete spec / api down, then public beta with a site, where people in the public can give feedback. Then 1.0.

Thoughts?

[sindresorhus]

@tony I would say land as many API changes as possible while it's still pre1.0. Much harder to do after it's stable.

[addyosmani]

I agree that we should try to land API changes pre 1.0 (yes to your
question about specs Tony) :) We should definitely do a beta to gauge
developer feedback.

Tony, that is absolutely awesome re:the open sourced production app. I'm
also pleasantly surprised you're well versed in the Facebook API. Would you
be able to talk a little more about the app you're working on? I totally
understand if keeping details private for now.

Really looking forward to seeing it :) let's make a call on FB client once
we've had a chance to review your app.

[tony]

@addyosmani yeah I made some decisions over the weekend.

1. Holding off on building a production application with aura until API is stable. After looking at the issues there are some pretty big architectural decisions that may go down soon.
2. I'm working on some tools for studying chinese. Here's one: www.hskflashcards.com

It's not ready for whole sale open sourcing. I could grab some of the views/css/behavior and move them into aura modules just using vanilla backbone instead of marionette. Create a local flashcard study demo with some theming perhaps? Achievements / Notification widget? Hashchanges / routing. I'm OK with contributing that functionality to the / an aura demo.

[addyosmani]

I could grab some of the views/css/behavior and move them into aura modules just using vanilla backbone instead of marionette. Create a local flashcard study demo with some theming perhaps? Achievements / Notification widget? Hashchanges / routing. I'm OK with contributing that functionality to the / an aura demo.

I think that would be perfect!

Regarding our API changes, I'd like to put some dates on #143 and #110 being completed so we have a better idea of when we can release. Shared data is definitely something I think we need to solve.

[addyosmani]

Hey guys,

// cc @tony @robertd @joelhooks @sindresorhus @rudolfrck @dusinboston @gersongoulart @pyramation @atesgoral

I really appreciate the momentum you've helped us achieve with some of the issues we wanted to address for V1 of the project. You've been awesome. To help us work towards a date for release, I've set a milestone of November the 15th for us having the V1 pre-release ready to review. Do you rockin' gents thing we can make it for that?

If it's crunch time, I'd love for us to get pull requests put together for #143, #110, #133 in the coming week. These cover shared data, individual sandboxes and improved Pub/Sub.

We have other issues like docs, demo apps and getting the release/site ready but I think between @tony and I we should have those covered. I'll be going through our docs to ensure that we're up to date at each point new functionality is introduced. I'll also help @tony with any clean-up/doc work he needs done on his demo app.

If you'd like to help our but don't currently have a piece of work assigned or a pull request that's been asked of you, there are two things you can assist with: reviewing and closing issues on the tracker (maybe we can get those down by half?) and unit tests.

In case you'd like some incentive: we're currently about on par popularity wise as the other Backbone extension frameworks, even though we haven't yet released our first stable version yet. I see this as a very positive thing. If we can pull off a release this month, I think in 2013 we have the potential to become the extension framework people use whenever they want to build non-trivial apps on top of solutions like Backbone.

We'll also be putting together a team site and making sure that you all get credit for helping make Aura an even better option for other developers to use.

Thanks for your continued efforts on the project. We really appreciate them!
Addy

[atesgoral]

I'm working on #110 as we speak...

[tony]

@atesgoral looking forward to it.

@addyosmani , @robertd @joelhooks @sindresorhus @rudolfrck @dusinboston @gersongoulart @pyramation @atesgoral

Knowing this, any of those major tickets could come in between and be merged in, so a rebase against may be needed. It's important to be sure that if your change alters behavior / changes the API, documentation and unit tests should be updated to fit with that. We want to be sure things take.

I have not yet begun looking at docs / demo closely because we're circling on rather large external API changes which could conflict with any documentation / demo we make. So I think it's important we get the big picture stuff PR'd ASAP, at least functioning and passing a spec.

I think us getting at a stable 1.0 pre-release will allow us to finally clear our head to play around with Aura on a few prod apps and see where we can go from here.

[addyosmani]

I think it's important we get the big picture stuff PR'd ASAP, at least functioning and passing a spec.

👍

[tony]

@addyosmani , @robertd @joelhooks @sindresorhus @rudolfrck @dustinboston @gersongoulart @pyramation @atesgoral

For 1.0, I'm beginning to think we should keep things where they are. A large API change needs time to bikeshed / meditate on. Much of what we are using on Aura is fine as-is. I'm open to an alternate 1.0 path, with a feature freeze:

1. Keep single sandbox / singular core context for now. Individual sandbox instances #110 or any external API change can come during a 1.1. This will give us more time to experiment with this approach and not have it added last minute.
2. Postpone sharing data Sharing data #143 to 1.1. However, use our practical scenario / our demo app to show data consistency in any clean way, which may bleed into core code a little bit.
3. Do wildcards in pubsub. Pub/Sub as part of core #100. This is a lower hanging fruit and should be started fresh, but can make 1.0.
4. Code cleanup. Have the core code make sense and demonstrate the mediator/facade pattern and abstraction of libraries in a citation-worthy fashion. Ultimately what brought me here is wanting to see the furtherance of Scalable Javascript Architecture and Large scale Javascript. Convey the principal / philosophy of aura.
5. Documentation.

Thoughts?

[addyosmani]

@tony my initial thought was that we would allow a period of time between landing API changes (e.g 1.0 pre/beta) and the final 1.0. Perhaps 1.0 beta in November and 1.0 final in January once we've all had time to test the changes more thoroughly? The alternative would be your proposal. I think both approaches have their pros and cons.

If we reduce scope, would we also plan on including your newer demo app as a part of the release?

[tony]

@addyosmani

We can consider that as an alternate release avenue if we're not able to get a feature freeze. This means we can have something better to say than just, "When it's done". :)

Re: demo app. Yes! I'm excited about creating a high-caliber flashcard app that demonstrates aura's principals. Widget for achievements, card display, routing to cards, and a control widget. i18n on the gui / strings. I'd be able to help best / start with the demo app if I can read/understand the core code and have clarity effort placed into it is going to stick. This could be part of aura's code if we decide it convey's what we want.

Regardless of if it's a feature freeze now or later this month, I have 3 feelings / desires :) :

1. to ship code that demonstrates a citation-worthy implementation of our patterns.
2. we're better able to help clean up code after new features and changes are frozen / merged.
3. I'm / we're better able to build demo app, docs and website after internal code is polished / cleaned.

edit: grammar / spelling

[sindresorhus]

I mostly agree with this, but I feel strongly that we should land breaking/big API changes pre-1.0. People expect stability in a 1.0 release, and this would limit our ability to make the needed changes afterwards.

[tony]

@sindresorhus

Yeah, slating big API changes to a 1.1 / 2.0 wouldn't be a first. It breaks apps. :(

Regarding API changes / in general I have some thoughts,

I am looking at how PEP / python work group handles API changes (http://www.python.org/dev/peps/pep-0001/). For instance, PEP-333 is a spec for web gateways, PEP-3333 furthers it. The mailing list is where the elders / community discuss / question / suggest.

I feel python's methodology is way overboard for what we need, but in context, we're releasing a framework people will build apps against. I think having the gate open to PR's, issues, suggestions, good docs, irc, etc. builds the community, I also think PEP-style proposals will land us with an API we're sure we want to keep.

Open source rocks. 👍

I think issues like #110 and and #143 would be awesome if we had the clarity of a PEP *

*sans the bureaucracy / red tape.

edit: just generalizing.

[PaulLeCam]

What about extensions?

Slide 71 of Zakas' presentation shows extensions around the core. Aura could stick to pub/sub and widgets management for 1.0 with only one extension for Backbone, and 1.1 could introduce new features as extensions that would not impact the core, but developers could choose to add to the sandbox.

[atesgoral]

FWIW, #110 seems to be non-breaking, at least in the scope of some basic smoke testing of the demo application. The reason the tests were broken is, the test runner itself is getting thrown off by something. I haven't had a chance to drill down on the reason as RequireJS dependency loading errors are usually not very helpful. Update: I've just fixed the outstanding issue with the spec runner.

[pyramation]

@tony @addyosmani for #143 I'd still like to get something by the date that has been set, although postponing is up to you guys whether it should be included. This can still move forward even if it's not included, I'm fine with that.

It does have some unsolved issues, which may warrant a postponement. So far I've been able to write the sandbox.data.create and sandbox.data.request, but have had some issues in regards to the way aura uses the localStorage to store models in the collections cache. For now I was playing with determining the collection by stripping the last part of the path of, e.g., events/:event_id => events, so that I can do proper saving on creating when making new models.

The other issue is the way in which extensions should be added to an aura project. The data extension I've created is modifying the core right now. Since it's not exactly clear as to the best way to add extensions right now, adding this extension may provide an example that people would follow for adding new extensions, so we should probably agree on the best way to extend the core.

[addyosmani]

Thanks for resolving some further issues on 110, @atesgoral :) I'm looking forward to us being able to land that work, whether its in the next release or the one after. If we do delay, I'm thinking maybe Jan or Feb for 1.1 would be a good target for a beta introduce should we want more time to test.

@pyramation Sharing data was probably the number one ask we had this year and I think its an important part of the project to get right. I'm wondering whether it should be a part of core by default, but it depends on the size of the overall work. Where possible yes, we should ideally be using extensions. I'm assuming data can't be done in the same way the Backbone extension was, just down to what its modifying. Maybe we need to introduce the concept of core extensions.

@tony would it be useful for us to define a feature freeze date by which we say "Okay. What's done and fairly stable? What are we happy to ship?", deferring those items that aren't complete for 1.1? We could change the release schedule to give everyone more time, but ideally we want to wrap up before December.

[tony]

@addyosmani I think the momentum driven by @atesgoral and @pyramation has re-energized me.

@atesgoral I'm watching #151 (PR from #110) and have your fork added to my remotes to test locally. 👍

@pyramation, if you like you can you make a branch and open a PR for your data implementation / #143, as you work on it.

From my POV It's kosher to open PR's even if incomplete and the build doesn't pass yet. To watch the branch and even to PR a PR if one of us has a eureka moment.

[addyosmani]

@tony Woo! I'm glad to hear that :) To add on top of what you've already said, everyone should feel free to ping us if they need helping or evaluating on-going work for PRs. Go team momentum!

[addyosmani]

I think we should use the V1 RC milestone to continue tracking progress of issues we want to tackle for the next release. Could everyone make sure issues you're addressing are captured here?

Going to do a sweep to add them in there now.

[addyosmani]

Just an update: @sbellity and I discussed it and we think that the next release should not be a 1.0 just yet. We've made a lot of large changes to the project and it would be good to have some space between 0.9.x and 1.0 to sanitize the APIs once we've offered developers a chance to play around with Aura some more.

[sbellity]

closing it