Recommended Posts

Jeez, Blaze, you're just letting life pass you by, aren't you? Have you done ANYTHING worthwhile lately?...except get your driver's license...and get accepted into college...and work on a kick-ass free piece of software? Jeez man, do something with your life! :p Seriously though, congrats on the driving test and college acceptance!

Do you guys think the May versions and Office versions will be available before the end of the month? I only ask as I am leaving the UK on the 30th to go back to South Africa and I could be bandwidth impaired for a few months. So need to know if I must get a friend to DL and mail to me.

Is anyone doing DVD's of AP in SA?

Do you guys think the May versions and Office versions will be available before the end of the month? I only ask as I am leaving the UK on the 30th to go back to South Africa and I could be bandwidth impaired for a few months. So need to know if I must get a friend to DL and mail to me.

Is anyone doing DVD's of AP in SA?

I really hope that May will be released soon?? Every month I have been guessing that within about 2 weeks of "Patch Tuesday" we would see a version released. I didn't understand there was so much more work that Blaze needed to get done for the release. Essentially, I am unable to give a "good" educated guess....all of mine in the past have been WAY off.

The Office releases.....I do not see them being released for at least a couple of months. I considered joining the Office team, but with everything I have on my plate I cannot do it.

I do the International DVD's and will ship to SA. Be forewarned though. I have shipped CD's/DVD's all over the world for the past 4 years (UBCD, UBCD4Win, and AP) and can honestly tell you that I have had problems with SA orders. People that have ordered have complained about an item taking a long time (2-5 weeks) to receive and have had several returned to me with no explanation. It's not a problem with all orders, I would just say it happens more frequently when shipping to SA.

Please DON'T post it on Slashdot, the mirrors are going to be hammered enough already considering everyone will be downloading full releases.

We've been Dugg before and survived :D

Anyways, if the HTTP mirrors go down, there's always bittorrent ;)

We've been Dugg before and survived :D

Anyways, if the HTTP mirrors go down, there's always bittorrent ;)

Bit Torrent is the proffered way to go for distributing something like this anyway. I think it should be released on a few trackers for a week or so initially, then put up on http for the nimrods who can't figure out how to set up a torrent client.

Bit Torrent is the proffered way to go for distributing something like this anyway. I think it should be released on a few trackers for a week or so initially, then put up on http for the nimrods who can't figure out how to set up a torrent client.

No, the HTTP releases and torrent releases should be concurrent. There are people who can't use one but can use the other - we don't want to go elitist on everyone :p

Bit Torrent is the proffered way to go for distributing something like this anyway. I think it should be released on a few trackers for a week or so initially, then put up on http for the nimrods who can't figure out how to set up a torrent client.

That really is an excellent idea, at least from the bandwidth perspective. It would be frustrating for those of us who are behind restrictive firewalls (my school blocks bittorrent altogether), but a week isn't terribly long and I suppose anyone who MUST have it can always find ways to get it (friends, hotspots.... the IT department head).

- Jacob

just to let everyone know, i've decided upon the solution to the prerequisite check problem now, so i can go ahead and implement it. i've also come up with something for the addon update problem!

What method are you using now?

What method are you using now?

static rti filenames with .ver files accompanying each one containing the version number. existance of xp_x86_enu.rti and xp_x86_enu.ver (or xp_x86_enu.rti.ver, haven't decided which naming structure to use yet) means an english xp x86 release exists (check #1: make sure update releases install on top of a release, and further more a release of the same type - prevent 2k updates installing on xp releases for example!). then we can get the version from the .ver file to do a comparison with a version defined in the prerequisite check for (check #2: only allow updates releases to install on certain releases).

doing a prerequisite check is simple, all you do is:

!insertmacro prereq_check 'filename' 'operator' 'version' 'description for error page'

e.g.

!insertmacro prereq_check 'xp_x86_enu' '>=' '20070501' 'autopatcher winxp may07 x86 enu'

version btw is made up of year+month+ver, where 'ver' is the version of the release. e.g. 20070502 means that it was released in may 2007, and ver=02 meaning there was a problem and the release had to be re-released as v2 for some reason.

you can have more than one check if you like, all checks must pass for the overall check to pass, however you could also stick in a '!insertmacro prereq_newGroup'. this starts a new group of checks, and only one group needs to pass for the overall check to pass.

the good points about this solution:

- static filenames means user has to change less things in the script every month, and no need to delete previous months rti files

- not easy to forget to update (hopefully we will have new rti file generator from raptor which does the job of creating the .ver files

- you don't need access to the previous release to know what version was to do a prereq check

- ver files for each rti file means combining releases (even via copy and paste) isn't a problem - no overwriting!

- overwriting will occur though if to releases of the same type are combined, but this is good because then you only have one rti and ver pair, the ones matching the file set you overwrote the other set with, therefore you know which release you have (from about screen in autopatcher.exe) and you can then bring it up to date.

there are no bad points for this solution besides the extra files, which we may be able to put in a sub-folder to be tidy.

---

the idea i had for the addon update problem: if you install an update release which contains an update to an addon pack, but the addon pack is not installed, but then it is installed later and therefore does not have the update to it the updates release would have otherwise installed, the update release could have cached the addon pack update that it didn't use, then when the addon pack is installing, it could check the cache and use any updates that are there. there could also be a /nocache switch for people who don't want such files cached and just want to get a newer copy of the addon pack at a later date if they want it, or who don't intend on getting addon packs.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.