quickly-talk team mailing list archive

[Didier Roche <didrocks@xxxxxxxxxx>]

Le lundi 20 décembre 2010 à 22:03 -0600, Umang Varma a écrit :
> Then update.py will check what the last update
> performed was and run the next update. This way, there will be no need
> to check for "symptoms" of old code--we will be able to update a
project
> based solely on which update was last performed.

Please, don't do that. This will force the user to make every update as
they come, and they will be blocked if they miss one update. In
addition, the current upgrade command already checked if you have the
latest version or not and launch upgrade.py only if you don't have the
latest code. So it's only executed once at each upgrade.



> We could include as many changes/refactors as possible in updates so
> that in all quickly code, it may be assumed that the current quickly
> project has the new code. Otherwise, if you write a new quickly
command
> `bar` that concerns a part of the code that was changed by an upgrade,
> you will have to check which version of quickly the project was
created
> with and maintain multiple versions of the command bar that behaves
> differently for different quickly projects depending on which version
of
> quickly it was created with.

This is called… debhelper and I don't know any other project that is
doing that :)
It's a complicated thing, headache and error proof. In addition to that,
we would explode the grid of things to tests and having a testsuite with
multiple projects states and such. I think this will bring more
regression than it will solve.

Right now, we don't have commands that really on a specify version of
the project, so I think we can continue with what we have today and see
when we will face this challenge. Ok, we got something similar in the
past with the licence command (where the input and output files have
been renamed). The command "licence" handles that itself to check all
the inputs needed are there. It's way safer than assuming anything as
the user can removed or modify a file himself.

> So in your example, updates #2 and #3b are
> not worth including. However, we will have to ensure that there is
> absolutely no code in quickly that assumes that changes like #2 and
#3b
> have been updated. E.g. in a future update or in a quickly command you
> cannot assume that code has been moved into a BaseProjectWindow class
> because that would be a false assumption.

It can be now handled easily in the upgrade command. There is basically
a function I wrote in the core where you have:
(file, "origin context code", "new code")
If origin context code is found, it's replaced by new code, otherwise,
nothing is done.

> 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.

Ok, I think that your previous comments came from a misunderstanding:
the project version is stored in .quickly file at the root directory,
and it contains the current version we have upgraded the project, not
the creation one. So I don't think there is an issue there.


Didier