quickly-talk team mailing list archive

[Michael Terry <michael.terry@xxxxxxxxxxxxx>]

On Mon, 2010-12-20 at 22:03 -0600, Umang Varma wrote:
> So I think it makes sense to go with your proposal and only include
> updates that fit your criteria. Also, like I explained, if updates could
> be made simpler to include, the trade-off would reduce. Finally, I think
> that eventually we will be forced to sunset old quickly projects and
> stop supporting projects created before XYZ. For that reason, I suggest
> that we begin to track with version of quickly a project was created
> with in order to end their life with sufficient warning. Before quickly
> eventually sunsets old code, we should examine every style of doing
> things in quickly and use the opportunity of not needing to care about
> old versions to change anything we may feel can be changed to make
> quickly more efficient.

You make a good point that's worth highlighting.  My proposal to not
worry about upgrades from older Quicklies would have the effect of
forcing the user to create a new project every year and port his old
code over.  That doesn't seem very good.

We may be forced to live with all versions of project_root forever,
unless we can find a way to write an upgrade hook for the bits we care
about.  :(

I like the idea of trying to moving code we're likely to change into
separate areas to discourage modifications.  I'm now thinking, for
example, that bin/project_name should only have initialization code and
the widget should be moved entirely into the project's module.

And this Builder class that is being worked on to simplify programmatic
access to widgets is really starting to feel like it should be in a
separate library (something like quickly.widgets).  It's a bit of common
code that we're sticking in everyone's project and we may want to patch
in the future.

But of course, this would mean forcing a dependency on a library we made
for all quickly-created projects.  I believe we have not liked the idea
in the past.

-- 
mterry