possible re-design of update mechanism?

[sriramab]

Is your request related to a problem? Please describe.
I'm always frustrated to update GAMA, there is always a chance of something going wrong. I propose two solutions, not sure how feasible they are.

Describe the solution you'd like
group the updates into understandable and transparent sub-sections or revert changes

Describe alternatives you've considered

Approximately, two years ago, GAMA introduced the most efficient and effective feature in GAMA: The Updates from within GAMA standalone. I cannot tell you how much I love this feature. But after two years when I review this, there is a strong urge in me to give this feedback.

Broadly, I do not wish to update whole of GAMA with all the commits every single time !

For example, I am using a stable GAMA that works for my project, no problems. it just runs beautifully flawless and more than my requirements. I am in a La La Land 🍻 🍺 winning people and winning students.

Then one (bad) day, I realize something is not working, like an operator or I would like a new operator. For example modification in skeletonize operator in last two days. GAMA team promptly addresses the problem and I am really thankful for that.

After a couple of hours of wait, now comes the time to update this operator. I say GAMA Help> Update. It updates the whole of GAMA. And then boom 💣 💥 . GAMA fails to launch. Change in workspace does not solve the problem. I cannot go back to older version. I cannot download older version. I am stuck with this flawed version, albeit temporarily, but still....I am stuck. Reason? Some other modifications were accidentally made by some other developers that corrupted the build.

Next, we report a issue, takes time to pin point the problem, may be half a day or full day or few days. Mostly less than a day, and we appreciate that.

if you consider the whole case, I just wanted to update skeletonize operator but ended up losing my working version of GAMA, stopped my work for a day or two, lost confidence of people, and also worried if other changes make my model inconsistent or invalid.

So, should I be spending so much time to update one operator?.. hmmm... may be there is a better option.

Solution: 1

Create an update such that the update can fold/ unload or expand/collapse to show the components of the update. For example, the update can show its components as:

• GAMA core update
• GAML modifications
• Operator Updates
• Skills or Plugin Updates
• GUI updates

I may not be using the correct nomination but I hope you get the issue.

If the update can be sub-divided or grouped as above, I as a user, will select just operator updates and hallelujah ! 🌹 .. I am clear in may be half hour and with just what the doctor prescribed and what is important for me!

Of course if there are internal dependencies within these groups, you can warn the user to update all dependencies.

To conclude: the large number of requests that come from non-computer scientists is enhancements in operators or in GUI and I am assuming this is a large section of GAMA user base.

Solution: 2

Considering the fact that GAMA is on git, could some functionality be built that user with a failed update can select, revert to previous version? that is , cancel or undo the recent update?

[AlexisDrogoul]

If it happens for every update then the problem is deeper.

Regarding your options:

• Option 1 is currently a no-no as it would require a complete revamping of the plugins architecture (so that operators are all in a feature, skills in another, etc.). And there are so many dependencies between them that I'm not sure the gain would be significative (i.e. GAML modifications often impact other components). GUI / Plugin updates are already a reality, by the way, since they are separated from the core, normally in their own features.
• For option 2, the possibility is normally built-in to manually revert the updates applied. Did you check it ? It should be in "Installation details" or something like this. If it doesn't work (I actually never used nor tested it) then we have a bug.

[AlexisDrogoul]

I forgot to mention a 3rd option, which actually has my preference given the rhythm of changes and the complexity of the platform:

• To establish a plan for upgrades (for example every 6 months) for complete stable releases, in which the update mechanism would be removed, and stick to this plan whatever the urgency to add a new operator or a fancy button in the UI. Then, in parallel, continue to have a nightly build and give the possibility to download for instance the 10 or 20 last ones.

That would make life easier for everyone. For developers, as we wouldn't have to really care about the state of the nightly builds and updates (no impact on the release), and for end-users (as the stability of the release would be left untouched and there would not be any temptation to update it). And for users wanting to absolutely test the new version, the nightly build would be available (but at their own risk).

The more I think about this, the more it makes sense. We just have to make sure we can have a stable 1.8 version (which is still not the case regarding displays).

[sriramab]

Sounds good to me. I would like to add: if possible there can be a download counter which can be a proxy indicator of which version is being mostly used or is popular or with a upvote - downvote like in app store. I know this can cause some spam voters... but just throwing an idea across.

With regards to 10 or 20 versions, I propose to store a fixed time release, because when developers are hyperactive there are may be 10 releases in just 2-3 days :) .. so lets say in 6 a month cycle you will have 20 releases. so that is update your last stable release.

[ptaillandier]

Do you think it is possible to "control" the update process, by enabling users to update GAMA only when a new stable version is available (ideally, with a more simple update interface)? 2018-07-27 9:36 GMT+02:00 Alexis Drogoul <[email protected]>:

…

I forgot to mention a 3rd option, which actually has my preference given the rhythm of changes and the complexity of the platform: - To establish a plan for upgrades (for example every 6 months) for complete stable releases, in which *the update mechanism would be removed*, and stick to this plan whatever the urgency to add a new operator or a fancy button in the UI. Then, in parallel, continue to have a nightly build and give the possibility to download for instance the 10 or 20 last ones. That would make life easier for everyone. For developers, as we wouldn't have to really care about the state of the nightly builds and updates (no impact on the release), and for end-users (as the stability of the release would be left untouched and there would not be any temptation to update it). And for users wanting to absolutely test the new version, the nightly build would be available (but at their own risk). The more I think about this, the more it makes sense. We just have to make sure we can have a stable 1.8 version (which is still not the case regarding displays). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/gama-platform/gama/issues/2483#issuecomment-408337858>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABb7HTW9wMRyNdJN0CsNL8ZZK9VTbWXjks5uKsLpgaJpZM4Vi_n5> .

[sriramab]

@ptaillandier would it not defeat the purpose of nightly builds or quick operator modifications that you or others do to address forum questions?

[AlexisDrogoul]

@ptaillandier @sriramab Having a fixed release plan should not prevent us from being able to release intermediary stable releases, for example to fix a huge bug. Maybe a simple check mechanism in the platform could warn the user that a new stable release is available (and downloadable).

[ptaillandier]

I am ok with this solution. The last thing, When GAMA 1.8 (stable) will be ready, we should improve the website, and in particular, the download page to make this new policy clear (and to be sure that "basic" users will download directly the good - stable - version). 2018-07-27 9:52 GMT+02:00 Alexis Drogoul <[email protected]>:

…

@ptaillandier <https://github.com/ptaillandier> @sriramab <https://github.com/sriramab> Having a fixed release plan should not prevent us from being able to release intermediary stable releases, for example to fix a huge bug. Maybe a simple check mechanism in the platform could warn the user that a new stable release is available (and downloadable). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/gama-platform/gama/issues/2483#issuecomment-408341396>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABb7HeCq_yUACF7lN9M9t_QGth-VR76Oks5uKsaigaJpZM4Vi_n5> .

[sriramab]

I dont mean a fix release plan, I just mean the quantity of previous versions to store should not be last 10 builds, but builds as they exist each sunday night GMT 00:00:00, so 6 months = 24 previous versions. If you do recent 10 builds, it could all be within a week.

Largely, I agree that my option 1 may not be feasible given the large dependencies.

But surely, something must be done to enable previous downloads if an update corrupts current installation.

Thank you both of you.

[hqnghi88]

Dear all,
I did not commented on this issue as i found the root post is about one "bad" day, without a reproducible manner. We are using a opensource platform, and there is always the risk to have such "one bad day" if we want to be updated (nightly build). It is the same on all others in the world, even with an OS (unix) or mobile devices. You cant ask for a commando mission to have a fancy button or operator without that risk.

Anyway, Sririma wasright in solution 1. We should try to distingue as much as possible. But we've already make it. We can chose which "feature" to be updated in the Installation Details dialog. In fact, all your needs are there, your can update/revert/remove an update. Just chose a good day to reorganize yours. In fact, there is some fail update cannot be revert. In that case, there is no technical solution as in eclipse, sometime i must reinstall a new, but it is extremly rare.

About the N builds, let say we have a downloaded stable release binary , you can chose to update to any version that still exist on server. Just in the update gui, uncheck the "Show only latest versions of available software" and you've got them.

[sriramab]

Well, I would like you to take a step back and think like a non-computer scientist. For them, a software crashing or not responding on an update is a big ...... . These are people who never heard of eclipse. These are brilliant minds in their subjects and are in a dire need of tools to evaluate their ideas. But, this can be a different discussion altogether.

After cooling off for a month or so on this discussion, I have this idea from what we already have. Let me know if it is feasible.

GAMA has now: a) RC (release candidate) b) NB (Nightly Builds) and c) Git versions. NB and Git are as they should be, user is at his own risk and that is understandable.

Now, for RC this is "supposedly" the best shot as a stable version. So the idea is (and I am being very specific wrt to user requests for operators only as these are the maximum) to have a tag in the commit statement that is recognized by travis in such a way that the operator is pushed to both NB and "RC update" . In this way, when a user with RC updates GAMA, he is able to get the operators only.

This means, GAMA should be able to detect if a user is using RC or NB.

Now one might argue, can we then call this an RC, in my opinion yes, it is an "updatable" RC like it happens in all software like Word Excel Acrobat-Reader etc. I may be wrong, but I do not think user request for operators are ground breaking ideas, they are usually to ease a multi-line code to a single operator that is more direct for the task.

I am just throwing an Idea, and you all might have a better way to solve this issue.

My concern is about what change in current update mechanism can bring maximum satisfaction to the user.

[sriramab]

applicable even for a bug fix to existing operator if not a new operator request.

[hqnghi88]

Staying up-to-date always has its price, not only in computer science domain, let's talk in another discussion.
All the solution had been listed. I prefered last year the restructuring but very feasible. I shown the existing mechanism of gama (eclipse). Option 3 only force us to make a release (how many people will follow strictly on that future release as we worked hard and still haven't 1.8 rc2 now).
I am the one who will argue that, what is different of "updatable" RC and NB? only operator because your needs is operators. I know a man who care on UX/GUI. Will us have "operator updatable" RC and "UI updatable" RC? We already have it, i talk about it above (updatable features).
In bref, the current build/release/update mechanism mostly have capability to satisfy us. It can produce a fix version, updatable version, updatable feature apart... just provide the "complete stable" moment.

[sriramab]

I agree with all you and alexis have been saying. I am just throwing my ideas to check if something is possible. I am no expert :)

Nevertheless, my last question is based on the revert option. Is there any mechanism so that GAMA can tell me, that the last version I was using is, example afg654ft or some commit code that I can revert back to?

Say if I update, then GAMA crashes. And there have been 32 versions between my last working version and the latest commit. How can I know which was my last working version? I do not think we can check this alphanumeric commit code inside GAMA, can we? Or is the recent item on "previous configurations" my last working version?

[hqnghi88]

I dont have a gama with several version but it is as same as in eclipse. You dont have the commit hashcode, but you have the suffix timestamp in the version. "previous configurations" is surely the next of the last line. you can remove seventy years old update by click on delete on its birthday, too. BUT when Gama crashes immediately, you dont have this magic.