Not.

_________________
bəʊɡɪ bəəs

PeStudio works OK on my Win7x64ultimate (no UAC, always Admin with full rights). It can scan itself and everything else (v. 3.34 now). I had some problems a few versions ago but not anymore.
I can make a video demo to prove I am not lying, but my word should be enough!

I still don't understand why it is not possible to update apps in the database (mainly change their version number) without pushing them in front more then 1-2 times/month?!

_________________
The Venus Project - Imagine Our world with No Laws, No Crime, No Wars, No Prisons

I think you hit the nail on the head. Maybe that's the simplest but best solution.

We shouldn't/can't control how the developer runs his show. He should be free to choose the software release cycle he is most comfortable with.

We should also keep the version number/info of apps in the database as up-to-date as possible. And we ought to thank users like Checker who works diligently to keep the database updated.

So the main issue is notification. Some don't like to see entries hogging the front page due to frequent updates. Others don't like to see the same entries in the RSS feed every day.

So if we change the rules such that a version update will only trigger a RSS notification (and move to the front page) if that entry has not been updated in awhile, that might be the best compromise. The database will still be up-to-date, but there will be no hogging of front page and the RSS feed.

Any objections? 1-month might be a little too long. I am thinking of a 2-week no-notification period between updates. So at most we will get a notification event twice a month for any particular app.

Real quick here,
the reason im iffy about this is what if theres a critical update, crashing/bug/security issue with some app and even though someone updates it, because its over its limit it wont get shown,
imo, while too many updates might be annoying for some, something like this might be worse,

so if you want to limit the updates, how about a check box or something that allows a critical update to bypass the limit if needed?

_________________
"It's not that I'm Evil, just that I'm unwillingly Good."
-Stolen, but oh so fitting. ^-^

Note: It might take me a while to reply to any post or comments due to offline reasons.
So if I don't reply or miss a question, this is why.

Just to clarify to make sure we are on the same page. If for example someone updates an app from 2.0.0 to 2.0.1, the update *will* be reflect in the listing. It just won't:

1) Bubble to the top of the list on the main page i.e. it will remain where it is, which is probably still quite near the top if the last update was recent eg. yesterday.

2) Appear in the RSS feed

Specifically because of this, i proposed the "accumulator" - it's also mentioned in the poll about this topic.

Short version: "Normal" assumed update schedule is 1/month. However, if an application does not update for a while, it can accumulate up to 3 "bumps". So in short: per month, you get one potential "bump" added, and you can "collect" up to 3 ones.

Does precisely what you're worried about: If an app updates often, it'll only get bumped once per month. If it has a more reasonable schedule, then it can accumulate a buffer of up to three bumps - and that way would be able to do an update, and then 2 quick more bumps in emergencies.

yeah, i understand that,
what im saying there should be a check box to bypass that and put it at the top of the list,
say an app caused a blue screen when run, and it was last updated to where its on page 2-3 by the time the fix came out, but its passed its update limit,
if the crash is fixed, it would be a critical update, imo, and Should be moved back to the top of the update list for ppl that check TPFC but maybe not the apps home page,

now, im not aware of anything like this ever happening around here, but when its comes to computers i tend to be overly cautious, so id rather annoy a few ppl with a new update then cause other ppl system problems,
ideally youd have a system where you could submit an app for an emergency update posting, that would then only get moved to the top after being approve by some of the higher ranked members,
but that seems more trouble then its worth, and i think the members here are good enough not to abuse a 'emergency update' check box,

@Lyx, yeah, i get what youre saying and its not a bad idea, im just more comfortable with a bypass in case its ever needed,
(though im also with Andy that a month is abit much, but eh, )

Side note though,
if youre separating the New Apps and the App Updates into two feeds, plus cutting the App listing down to 1-2 line(s), do we really Need a limit on how many times it can be updated?

_________________
"It's not that I'm Evil, just that I'm unwillingly Good."
-Stolen, but oh so fitting. ^-^

Note: It might take me a while to reply to any post or comments due to offline reasons.
So if I don't reply or miss a question, this is why.

I see a few problems with this:

1. This would only be useful, if the users know that its a critical update. So, a critical update would need to be marked.
2. WHAT is a critical update? Modern practices of software-design have resulted in almost every update containing fixes to things like code-injection in 3rd party libs and stuff.
3. Do we even have the ressources to identify most critical updates?
4. What about applications that have a devstyle that is prone to frequent critical fixes?

IMO, it is not possible to do this job reliably, and thus it is okay, if we cannot take such things perfectly into account.

I'd therefore retreat from my accumulator proposal, and instead propose something more simple:
1. Two weeks must elapse between bumps. If an app is updated quicker, the bump is scheduled to happen automatically after the two-week waiting-period is over.
2. Only high-profile members (i.e. Checker) can override this restriction by checking a "Critical Update" box. They should only do this if the past version contained catastrophic issues (i.e. userdata-loss. Plain run-of-the-mill code-injection isn't enough). The app will in this case be shown with a "critical update" icon, instead of "update".

Thanks for the honor
But I don't like the idea of being responsible for the decision what's "important" and what's not.
For example: A software updates the version number, but the onliest change is adding a romanian language pack.
That's not so important for me, but maybe important for users like joby_toss.

I don't like the idea of "hiding" the updates. The update should be available immediately ... and the database as up-to-date as possible