Most larger packages have lots of separate, relatively independent, files that might need to be updated independently, and earlier than, a new release of the entire package.

e.g. compilers (like my Modula-2, E, etc) may have dozens or more support modules. Same would be true of C programs intended to be delivered in source form and then built. Even the simplest package will have separate documentation that usually lags behind the actual program and is often intended to be updated later.

At least, that's the first thing I thought about when I started looking into using AmiUpdate. Many fixes or additions you want to get out quickly, without waiting until you've got everything done you wanted to do for the whole package.

I am seeking advice on the best way to do that.

Any ideas on the best way to configurate this sort of thing with AmiUpdate?

Two approaches occur to me right away:

• Just add a newly named entry into the AmiUpdate DB for the module to be updated.
  But this could get unwieldy.

• Include a Release file with $VER number independent of your main program version
  and keep track of which module updates bumped which Release subversion numbers.
  But this could get tricky if someone missed a lot of releases.

What do you think?

Tom