Just a suggestion but prior to releasing major upgrades would it no make more sense to test it thoroughtly as there is an upgrade every few weeks! I continue to have head aches with this script esp after the updates.
At $100 it should not be too much of a requirment I would have thought.
No amount of testing I can do will imagine the infinite possible configuations, so bugs are an inevitable consequence of adding features. I can only make a point of offering prompt fixes to those which are reported to me.
4.0.41 is an older stable option with less frequent updates if you're the conservative sort, which is why it's listed in the downloads area as the stable series. 4.1.x predictably has had its share of bugs because only three or four people actually tested the betas during the months-long testing period. If you know how I can hire a testing team while making $17,000/year net (and throw in California's cost of living), I'd love to hear it. As for more testing of the revision releases, these are in fact largely bug fixes, and most people would like the fixes promptly (admitedly I sneak new features in, but I try to make sure these are things which won't affect the stability of preexisting features). 4.1.6 is the one release which I can see a good argument that more time should've been taken on, as the memory reduction work was on the dangerous side and did introduce a couple of new bugs... other than that, the 4.1 releases haven't involved any regressions that I recall. And suffice it to say you aren't talking about 4.1.6 if you're using 4.1.4, anyhow.
The autoupgrade is a very new especially tricky option which had a bug for people whose base directory wasn't chmoded 777 in 4.1.4, and a different bug in 4.1.6/7. It should soon become as reliable as we both hoped it would be already.
You appear to have the 4.1.4 chmod issue. You can work around it by manually chmoding your base install directory to 777 and then running autoupgrade (should work then), or you can upgrade the old fashioned uploading way as described in readme.html.
Thanks Paul.. I wasn't having a go at you merely just an observation. I will try cmodding the base directory to 777 and see what happen. BTW - perhaps inviting more Beta testers prior to going live might help for a discount fee?
0/5
1
2
3
4
5
This thread is closed, so you cannot post a reply.
Comments on Error Message
Member
Usergroup: Customer
Joined: Sep 09, 2007
Total Topics: 13
Total Comments: 24
What does this mean when trying to update links through the back end?
Does this mean that none of my previous updates have worked - even though they say they have?
Warning: ftp_site(): No file name in /home/offer/public_html/includes/filefunctions.php on line 168
Warning: copy(../newposts.php): failed to open stream: Permission denied in /home/offer/public_html/includes/filefunctions.php on line 32
Warning: ftp_site(): No file name in /home/offer/public_html/includes/filefunctions.php on line 168
Warning: copy(../config.php.txt): failed to open stream: Permission denied in /home/offer/public_html/includes/filefunctions.php on line 32
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
You need to specify your version number.
Member
Usergroup: Customer
Joined: Sep 09, 2007
Total Topics: 13
Total Comments: 24
Version 4.1.4 I think...
Just a suggestion but prior to releasing major upgrades would it no make more sense to test it thoroughtly as there is an upgrade every few weeks! I continue to have head aches with this script esp after the updates.
At $100 it should not be too much of a requirment I would have thought.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
No amount of testing I can do will imagine the infinite possible configuations, so bugs are an inevitable consequence of adding features. I can only make a point of offering prompt fixes to those which are reported to me.
4.0.41 is an older stable option with less frequent updates if you're the conservative sort, which is why it's listed in the downloads area as the stable series. 4.1.x predictably has had its share of bugs because only three or four people actually tested the betas during the months-long testing period. If you know how I can hire a testing team while making $17,000/year net (and throw in California's cost of living), I'd love to hear it. As for more testing of the revision releases, these are in fact largely bug fixes, and most people would like the fixes promptly (admitedly I sneak new features in, but I try to make sure these are things which won't affect the stability of preexisting features). 4.1.6 is the one release which I can see a good argument that more time should've been taken on, as the memory reduction work was on the dangerous side and did introduce a couple of new bugs... other than that, the 4.1 releases haven't involved any regressions that I recall. And suffice it to say you aren't talking about 4.1.6 if you're using 4.1.4, anyhow.
The autoupgrade is a very new especially tricky option which had a bug for people whose base directory wasn't chmoded 777 in 4.1.4, and a different bug in 4.1.6/7. It should soon become as reliable as we both hoped it would be already.
You appear to have the 4.1.4 chmod issue. You can work around it by manually chmoding your base install directory to 777 and then running autoupgrade (should work then), or you can upgrade the old fashioned uploading way as described in readme.html.
Member
Usergroup: Customer
Joined: Sep 09, 2007
Total Topics: 13
Total Comments: 24
Thanks Paul.. I wasn't having a go at you merely just an observation. I will try cmodding the base directory to 777 and see what happen. BTW - perhaps inviting more Beta testers prior to going live might help for a discount fee?