quickly-talk team mailing list archive
-
quickly-talk team
-
Mailing list archive
-
Message #00007
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