← Back to team overview

quickly-talk team mailing list archive

Re: Scope of upgrade command

 


On 12/21/2010 07:51 AM, Michael Terry wrote:
> 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.  :(
Yours response made me think of another idea that would be more like how
the rest of the world achieves this: say there comes a time in the
distant future that we cannot support old projects anymore, we simple
fork the `ubuntu-application` template, make a lot of changes we
consider awesome that break backward compatibility and implement them in
an `ubuntu-application2` template. That way, old projects can still use
the old template  but no new features and no further refactoring will
take place in ubuntu-application (only bug fixes). We can also set an
end of life for ubuntu-application and stop supporting it after X number
of years.

> 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.
Oh. I wasn't aware of that. What is the reason behind that? Also, would
shipping the library as part of the application as opposed to as a
dependency be liked more?

Umang



References