Versioning system needed for recipes

Case number:845813-987845
Topic:Game: Tools
Opened by:Tlaloc
Opened on:Friday, June 11, 2010 - 13:01
Last modified:Wednesday, August 28, 2013 - 01:23

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.

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.

(Fri, 06/11/2010 - 13:01  |  16 comments)

Joined: 09/18/2009
Groups: SETI.Germany

This is why I most times delete the old ones.
It gets too confusing.

spmm's picture
User offline. Last seen 23 weeks 18 hours ago. Offline
Joined: 08/05/2010
Groups: Void Crushers


Joined: 09/24/2012
Groups: Go Science

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

Joined: 04/15/2012
Groups: Beta Folders

Also, how many downloads.

Maybe all these things since script creation?

Joined: 09/21/2011
Groups: Void Crushers

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)

Joined: 04/15/2012
Groups: Beta Folders

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?

Joined: 09/21/2011
Groups: Void Crushers

Why 3? ..
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.

Joined: 09/21/2011
Groups: Void Crushers

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.

Joined: 04/15/2012
Groups: Beta Folders

Ok, I got it. Thanks (And yes, I do get what you're saying about bugs!). Now that you mention it, that would be a good way for me to mark my future scripts.

Joined: 09/24/2012
Groups: Go Science

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

Joined: 09/21/2011
Groups: Void Crushers

Only the highest version I do maintenance on. So the other problem is still in earlier versions.
Not have had the time to fully investigate what good 'idealize' can do inside scripts except for some tiny experimental scripts.

spmm's picture
User offline. Last seen 23 weeks 18 hours ago. Offline
Joined: 08/05/2010
Groups: Void Crushers

My preference as a user of recipes is to choose when to update, not to have them automatically changed without me being aware of it. particularly as in my experience fixes can introduce other changes or errors even when written by the best run software development houses with great coders. Changes may also change how the recipe works in particular situations. It may be an improvement but not for the particular use case.

I truly appreciate and value the great coders who provide us with recipes. Thanks :D

Joined: 04/15/2012
Groups: Beta Folders

Also, perhaps older versions could be kept available as well?

Joined: 09/21/2011
Groups: Void Crushers

Two things:
What is the report to Mollem link about?

And in the current system, if I overwrite an existing recipe, the previous version is no longer available on the site.

Joined: 04/15/2012
Groups: Beta Folders

1. No clue. Something with the captcha

2. Yes, but some may want to see an old version. Also, some occasionally upload a fresh one (not overriding) for this reason, though I could be mistaken.

spdenne's picture
User offline. Last seen 23 weeks 1 day ago. Offline
Joined: 10/01/2011
Groups: Void Crushers

Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, RosettaCommons