Versioning system needed for recipes

Started by Tlaloc

Tlaloc Lv 1

The current versioning/voting system for shared recipes has problems.

People tweak recipes all the time trying to improve them. The current system has the following problems:

  • If someone downloads a shared recipe, there is no notification when that recipe is updated.
  • There is no way to assign version numbers, other than what people currently do, which is put it into the script title.
  • Votes for a script don't persist if a new version of the script is made. </ul> Each shared recipe should have a version number with a major and minor part, such as 3.02. All recipes should start at version 1.01. When a change is made to the recipe and it is re-shared, it can be either a major change or a minor change, as chosen by the author. A minor change should increment the minor version number by .01. A major change should reset the minor part to .01, and increment the major part. Votes for a script should persist across all minor version number changes. Major version number changes should lose the voting. Children of a recipe should be tied to a particular major version number. A minor change should replace the version that is on the web site with the new version. A major change be added to the web site, leaving the previous major changed version. The author should have the option of deleting versions of the script that are on the web site. When a user runs a recipe, it should check against the web site to see if the version being run is the latest version, either major or minor. If it is not, then foldit should offer to download the latest version to the cookbook, replacing the one that is there.

Bruno Kestemont Lv 1

The present recipe's scoring and ranking is a kind of Recipes Hall of Fame and grateful for their authors. Combined with the date, one can try to identify pertinent recipes.

But it does not help users to find the recent "hot" recipes, or simply the latest version.

Often, a newer version is bug-free, but an older version has more votes and stars (example with the tvdl enhanced DRW series: the latest, perfect, version TvdL enhanced DRW 2.3.0 has only 5 votes, the older one, the famous Tvdl enhanced DRW 1.2.4 has 167 votes and will remain high on the rank for long). As an author, if you want to keep your votes, you have to keep the version and simply update it o the server. I thus support the proposal made here, allowing the author to keep votes on minor versions or start with a completely new version, keeping old versions on the site for fame.

I would also or alternatively appreciate additional info behind the recipes list:
-how many times used per month (latest 3 months) and per type of puzzle (could this be tracked by the client and sent to the server)? Like in the Nature paper, but 'on the fly'.
-a separate ranking list with only latest year 80% better votes (20% could be unfortunate users who did use the recipe without knowing the use of them, or old users that encountered a bug which is fixed in the newer update).
-a yearly (or permanent continuous year average) online voluntary survey where we check our 10 preferred recipes of the moment also giving an attribute for the "best fit" type of puzzle and another for the "best fit" moment of the game (begin, mid, end).

Timo van der Laan Lv 1

I agree with the suggestion for a versioning system.

However I would like to see 3 numbers in the version.

.. Normally I try to update a version by editing the versionnumber in the recipe info and share that. If done that way the votes stay intact. However 2.3.0 was an emergency release because of the changed name of the density component of the score. DRW enhanced versions: 1.2.4 167 votes (started at 1.0.0!) 2.1.1 117 votes 2.3.0 5 votes (And Bruno, no software is perfect, but I try to get close)

AsDawnBreaks Lv 1

Just out of curiosity, why do you need all 3? Is there really that much there?

And how about you can leave off the last number if you want?

Timo van der Laan Lv 1

Why 3? <main version>.. Subversion for not too big functional changes. Main version for big changes either in functionality or structure of the program. (The main difference between version 1 and 2 of DRW has been a large cleanup and making (reusable) modules of parts of the program) Bugfixnr, I wish I could write bugfree software.

And making 3 an option is okay with me.

Timo van der Laan Lv 1

Somehow my previous post got messed up.
So again:
Why 3? mainversion.subversion.bugfixnr
(In both my previous postings I used the less than and greater than characters around it, it looks like that is something to avoid in postings)

Main version: for big changes in functionality or structure of the program
Subversion: for not too big functional changes.
Bugfixnr: I wish I wouldnt need this one but bugfree software…….

Making 3 numbers optional is okay with me.

Bruno Kestemont Lv 1

Timo: if I understand well, all current versions on the server are (almost) bug-free? What about the 'other' problem in versions 1 and 2.1.1?

(+did you implement the 'idealize' function proposed by Marie-S in her 'long' version - I don't know if it works, but I tempt to prefer this one on middle game).