|
That's not necessarily true.
Features may be added later that weren't feasible to release in prior versions due to budget and time and quality. Operating systems change, and apps are updated to take advantage of newer OS features (like shell JumpLists in win7+)
There are plenty of reasons to update an app that don't have to do with quality.
Frankly, you making such a statement just leaves me puzzled. I want to think you're joking.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: Frankly, you making such a statement just leaves me puzzled. I want to think you're joking.
Not at all. I never updated anything just for the sake of updating. I prefer stability, especially when I have no choice.
honey the codewitch wrote: Features may be added later that weren't feasible to release in prior versions due to budget and time and quality. Ok, but please the honest way and not like Mickeysoft who desperately had to move stuff around every two years so that they could sell you the next 'improved' windows.
honey the codewitch wrote: Operating systems change, Sure they do, but I don't play along. Often enough I don't even have a choice as the OS version targeted is required. Too bad when countless thingies want me to move to a higher version. Guess who gets the short straw in that case.
honey the codewitch wrote: updated to take advantage of newer OS features Yes, don't you have a ribbon yet? Much of that is shoehorned in because developers want to use that new cool stuff, not because it really helps so much. Even if it does, it's a feature that was usually not asked for or expected. There are actually those who liked the old version for a reason and don't like like to see when some things they relied on are 'improved' to death.
And these are my personal 'favorites'. I throw everything of that sore out faster than a cat gets out of a full bathtub:
1) Nagging updaters that constantly 'remind' you that you should update.
2) Updaters that don't want to leave you any choice and want to do their updating before ever starting anything. Always happens when you don't have any time or nerve for this sh*t, like when you are getting your notebook ready for a presentation for the bosses. Bonus points if the updater messes things up so well that your presentation falls flat on its nose in front of some already impatient bosses.
3) Updaters that download huge installation packages in the background, hogging up your bandwidth and download volume without asking. I often have to rely on mobile internet and Mickeysoft lost a customer in me when they tried to update my Win7 installation to Win10 without asking and eating up my download volume for the month. Sorry, Mickeysoft, but I let you pull such a trick off only twice. The first and the last time.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I get it you don't like updaters.
But you didn't actually undercut my point that updates aren't necessarily about quality.
You don't like new features. That's fine. Other people do.
It has nothing to do with a quality assessment and everything to do with your annoyance at the very idea of software ever changing.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Or documentation.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You must be a manager
|
|
|
|
|
Hope you are talking about Browser / Desktop Apps & not Phone Apps as it's impossible.
|
|
|
|
|
desktop apps. i don't care about phones =)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Message Closed
modified 19-Aug-19 2:56am.
|
|
|
|
|
umm, it's already finding updates on github, bootstrapping an updater, downloading, unzipping, and rerunning the original (now updated) app.
so what now, Bill?
If you want to wager money on me producing this EOD (pacific standard time), i could use the extra cash
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
How much do you trust Github?
|
|
|
|
|
Trust is relative. What am I trusting them with?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Your reputation for a starter.
It would depend on how your auto update is supposed to work obviously, I also don't know how atomic Github is. Git as such struggles, but that's mostly depends on the users of course.
|
|
|
|
|
All I'm doing is scraping a repo's releases for special "refresh" releases that contain the binaries for the app, doing an http request to fetch the zip, extracting the zip to the bin folder (after the app is closed) and then rerunning the app with the same command args it was started with originally.
I'm not building from source or anything so i'm not sure what you mean.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: I'm not building from source or anything
My fail, that's what I thought.
|
|
|
|
|
Well, it's understandable. I should have been more clear. The reason I thought github might be a good idea for this is for open source projects it already holds things like releases and branches and stuff, so you can point it to a stable set of releases and manage your updates in the same place you manage your source for the apps, which makes sense to me.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
In that case I don't see it as a terrible idea, it's just another storing place.
One of the pros is that you can allow users to select the version to install, in case there are problems with some versions.
|
|
|
|
|
That's a double edged sword. I might make a backdoor for support that allows me to override a version but by default i think i want to make it grab the latest.
The reason being is it will cause more people to harass me if they keep screwing up their versions by installing explicit ones
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Well, you could have a list with allowed version...
But I understand what you mean. It's just that I personally would like to be able to demote some programs to earlier versions. Major versions especially.
|
|
|
|
|
I'll consider it. It's easy enough to do.
Here's the code to choose the update version now (I have a list of all available versions and their associated .zip urls)
sb.Append(_Esc(_VersionUrls[LatestVersion].ToString()));
Ignore the surrounding code, but see the LatestVersion call?
it's not hard to add to this.
The trouble is, there's no UI for choosing the version, and it would be silly to add one.
So i think if they want to choose a different version It won't be autoupdate.
They'll have to force an update with version specified explicitly.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: They'll have to force an update with version specified explicitly.
Fair enough.
But there would need to be a list with versions and an instruction.
|
|
|
|
|
I've got that, and I'll add it the instructions on how to do it to the CP article.
It's a bad idea to make it easier than that, IMO, because it shouldn't be done.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
I wouldn't go so far as to call it terrible, but neither is it a good idea, IMO.
In any medium to large project, I try to not to change the tools (compilers, external libraries, etc.), unless a major bug is discovered that prevents the completion of the project. It is my experience that tools are never completely backward-compatible; there is always some new feature that breaks old code. This means that any tool change requires a complete re-test of the entire product.
Note that I do not dispute that in many cases the new features are improvements; I claim that integrating them in the middle of a development stage is a bad idea. At the end of the stage, I would consider upgrading tools that provided significant new functionality / bug fixes, because the new product will anyway have to undergo a full test.
What I might do in your place is to provide a notification that a new update is available, and allow the programmer to decide if to upgrade.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I don't think i was very clear about a crucial aspect of this, which is my bad.
This project (I already built it) draws from "releases"
And the releases it draws are special release you prepare specifically as application "refreshes"
They are of course, built from the code at the github repro, but it only draws from actual releases you make, and even then, only ones you specifically set up as application updates.
so in a sense, it's just using github as a filestore for release executables, but i guess looking at it that way makes it seem almost like theft at least now that i think about it. I wonder if this violates GitHub's ToS in some way? I don't think it does. Hmmm
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
As terrible ideas go, it's a great one.
As great ideas go, it's a terrible one.
As ideas go, it is neither terrible nor great until the responses it receives.
|
|
|
|