AmiUpdate - different modules in a package

4 posts / 0 new
Last post
tbreeden
tbreeden's picture
Offline
Last seen: 3 years 2 months ago
Joined: 2010-12-09 03:10
AmiUpdate - different modules in a package
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
cha05e90
cha05e90's picture
Offline
Last seen: 2 years 8 months ago
Joined: 2011-02-07 20:22
I've not looked very deep
I've not looked very deep into this new package, but maybe this (idea) might help. Looks like some kind of "AmiUpdate for all". Mainly a MorphOS software, but Guido tends to do binaries for OS3 and OS4 as well (untested). http://www.geit.de/eng_grunch.html After a quick read I found nothing which couldn't be done with Simon's AmiUpdate as well - but (as always) it heavily depends on the developers and those who maintain the database entries...
X1000|II/G4|440ep|2000/060|2000/040|1000
Rigo
Rigo's picture
Offline
Last seen: 1 month 1 week ago
Joined: 2011-01-24 21:55
It all depends on how
It all depends on how complicated you want to make things. The AmiUpdate database contains fields for required and dependent components. Whether these can be used for your particular application, I've no idea without knowing on how you plan to package and structure the update archives. Perhaps one solution might be to have a main archive, a support archive and a documentation archive. That way it's only three entries in the database (easier to manage), and each archive will install all of the latest components relative to it. This way you should be pretty well guaranteed to be checking against a known component and be able to rely on the version information. Simon
tbreeden
tbreeden's picture
Offline
Last seen: 3 years 2 months ago
Joined: 2010-12-09 03:10
Thanks. I'll give it a
Thanks. I'll give it a go. Tom
Log in or register to post comments