WACUP
General => General Discussion => Topic started by: dro on January 19, 2017, 05:22:18 PM
-
One of the pains that Winamp had was too many keeping using older versions instead of wanting / being able to use newer versions.
Now as we know the WACUP beta builds expire after a time (which is being refined over the builds released so far) as a means to keep active use on the current builds to minimise support burden (e.g. not having to re-test multiple versions).
From the beta sub-forum thread about the expiration issue, one thing that has come up which I'm really not sure about and that's whether for eventual release builds if a similar thing would be acceptable (e.g. when a newer release build comes out, should it effectively push the new version to be used in some manner) or is it best to accept a fragmented user base as the norm and leave the control of updating in the user's hands so as not to be evil ?
Thoughts and suggestions below please. As I think for beta builds it's ok to have them expire, but for release builds it makes me feel uneasy.
-dro
-
Well ... for instance I like my Firefox auto-update feature...
Would like to see that on Winamp too 8)
-
DrO,
In my opinion there should be some updater application for WACUP.
Updater should by default check for update on each run of Winamp. There must be option to disable update check. There should be some options that allows to set how often should Updater check for new versions (every run, every day, on each 10 days etc)
For sure - user should decide. WACUP with expiration builds is a very bad idea (for beta is OK)
-Pawel
[edit - dro]
fixed some odd formatting in the message
-
I am also a fan of auto updates. It works like this on our phones now and it doesn't seem to be a problem.
Personally I get annoyed when someone asks for a feature or is wondering why something is crashing and the problem could have been solved by updating to the latest version. I would definitely be a fan of builds that expire or get disabled when the new build comes out. (This is assuming that you don't have to pay for the upgrade. If you have to pay for the upgrade, then it is evil!)
-
Well, I'm a software update control freak I guess. I opt out of all auto updates. (Windows, Browsers, Flash, WordPress, etc, etc.).
Now, I do routinely check for updates (installed several Windows Updates today) and install them when I am ready to deal with the consequences and it gives me time to backup things before hand.
I am fine with something saying that an update is available, but I want to say when it actually installs that update.
I think the auto-update stuff is really meant those people that never bother to check for updates on their own. I am OK with an auto update being the default. I just want to be aware of that fact and able to turn it off.
-
I would love for it to notify you when a new version is released
then you have two weeks to update
if you don't update in that two weeks, then the version you are using is disabled.
-
if you don't update in that two weeks, then the version you are using is disabled.
Very bad idea!
New version is not always the best option for user. There may be resons that user stick with specified version.
So, never, never decide for user!
Maybe you just could built-in some mechanism that check if WACUP is updated or not - if not - user can not sent error feedback - instead he will be asked for installation new version.
-Pawel
-
if you don't update in that two weeks, then the version you are using is disabled.
Very bad idea!
I'm full of bad ideas. It's my trademark.
-
Is a tricky one... my preferences would be:
- No auto update without user's consent (but it could have an option to set it like that)
- No expire date (as Pawel said: "There may be resons that user stick with specified version") * .
- Do warn there is another version when it comes out and / or at certain periods of time (every 2 o 3 weeks, etc -with option to turn this warn off-).
* Besides, giving the option to the user to update or stay (because of x issue implemented by a newer version), can leverage the developer of having to consider a EVERY POSSIBLE scenario and focus on the most important issues / bugs.
-
Am going to give some quick replies to the points raised so far (thanks for what has been mentioned / commented on!).
Will provide a more formal response / proposal when there's a bit more feedback and I've let the common things settle out :)
Well ... for instance I like my Firefox auto-update feature...
Would like to see that on Winamp too 8)
That was the first suggestion by QOAL via twitter and effectively going with more of an app style update setup.
My only concern about going that route is the need to either have another dedicated program / service (as in the cases of Firefox, Chrome) and then trying to ensure that it doesn't cause any issues (especially if setup as a background service which part of me finds a bit excessive for a media player).
-dro
-
In my opinion there should be some updater application for WACUP.
Updater should by default check for update on each run of Winamp. There must be option to disable update check. There should be some options that allows to set how often should Updater check for new versions (every run, every day, on each 10 days etc)
For sure - user should decide. WACUP with expiration builds is a very bad idea (for beta is OK)
Ok so have whatever the update mechanism is enabled by default and make it so it's easy enough to disable (which seems the right way to go anyway).
The frequency of doing update checking probably should be slightly less frequent than say on every start-up attempt / once a day. As even if it's done threaded, it still introduces some overhead that isn't needed most of the time. So more like once every fre days / a week is more likely a reasonable starting point as the release builds aren't likely to come out daily (though that would be amusing to emulate that aspect of the 2.x development days when everyone complained about too frequent updates).
The expiration aspect in a release build also didn't sit right with me hence the need to see what others think. Though I get why it's appealing as keeping old builds around also has it's own issues (which I think will be addressed a bit more in a reply to one of the later posts).
-dro
-
I am also a fan of auto updates. It works like this on our phones now and it doesn't seem to be a problem.
Personally I get annoyed when someone asks for a feature or is wondering why something is crashing and the problem could have been solved by updating to the latest version. I would definitely be a fan of builds that expire or get disabled when the new build comes out. (This is assuming that you don't have to pay for the upgrade. If you have to pay for the upgrade, then it is evil!)
The mobile / app model is relatively easy to emulate by getting an update only installer and just running that. The main issue then is how to handle when new parts are added i.e. just install or require the user to manually get involved (be that a setting or default so as to not be 'evil' in just installing whatever which if you want to keep the install under control would be needed).
The main issue with expiration of builds is what happens if the new version is less stable compared to the prior version? As I've thought a bit about this with the beta builds and the changes for it's handling of expiration (so I can if needed fiddle things to make a prior build still work if the current beta ends up being bad). But then I really need to improve my processes so that I'm doing more rolling updates if there are key things that need to be fixed (e.g. I should have just done a newer installer with the fixed gen_undo / gen_classic but then I'd not expected other things to happen that distracted me).
With betas it's more ok to have them expire so that things are moving forward but for release builds (where there's a greater expectation of it just working ok) then it probably doesn't fit right (however much I'd like and agree with keeping a user base to a recent version of the software). As I'm not sure it'd even make sense to say allow for all v1.0x to work and then when a v1.1x comes out for that to eventually led to those v1.0x to expire (as v1.1x may not fit needs and instead just puts people off the software as a whole).
What people don't like paying for updates? Aww and there I was hoping to use that as an income model, heh (am joking however tempting it would be ;) ).
-dro
-
Well, I'm a software update control freak I guess. I opt out of all auto updates. (Windows, Browsers, Flash, WordPress, etc, etc.).
Now, I do routinely check for updates (installed several Windows Updates today) and install them when I am ready to deal with the consequences and it gives me time to backup things before hand.
I am fine with something saying that an update is available, but I want to say when it actually installs that update.
I think the auto-update stuff is really meant those people that never bother to check for updates on their own. I am OK with an auto update being the default. I just want to be aware of that fact and able to turn it off.
I was always intending having a means to opt-out, it's whether things should be on by default and then where to make it obvious that updating can be opted out off (i.e. just via preferences or during the setup process as a whole).
This is why I'm asking as just from a few posts it's clear that there's a difference in view point when it comes to updates (from just update automatically to wanting manual control over when an update happens). As I get wanting to have control from a user view point as I do it a lot myself, though from the developer view point, having everyone on the same thing (or as near to) makes life so much easier from a support / development view point. Thus the need to work out what's the best balance between my ideal needs and those who want to use WACUP.
So the main thing I'm taking from your comments is updating is ok as long as there's a decent way to opt-out as needed but it's still ok to indicate a newer version (but without it being too naggy).
-dro
-
Will treat these together...
I would love for it to notify you when a new version is released
then you have two weeks to update
if you don't update in that two weeks, then the version you are using is disabled.
Very bad idea!
New version is not always the best option for user. There may be resons that user stick with specified version.
So, never, never decide for user!
Maybe you just could built-in some mechanism that check if WACUP is updated or not - if not - user can not sent error feedback - instead he will be asked for installation new version.
I mainly agree with Pawel on the point raised as even if I do my best bugs can and do creep in which often don't show up for a while. So in that case it's generally going to be better to not expire (as covered in some of the earlier replies).
I get why it makes sense to expire (as done for the betas) but I think those more willing to use beta versions are more forgiving compared to those who will only ever use a release build (even if it's the same thing with just a high level of certainty that it should work ok). I used to see the same when working on the SC DNAS where some wouldn't touch the build if it was described as beta but with that same compiled version put out under a release moniker would then use it (and it was the exact same file in some cases).
As for the part about not deciding for the user, that has to happen to an extent based on what the default updating options end up being. Hence why I'm asking now before even implementing anything so as to hopefully get those defaults correct whilst accommodating what others may need (like with the means to opt-out but still get notified even if the update isn't auto-downloaded / applied as such).
The final point by Pawel about blocking feedback is an interesting idea but that does somewhat seem a bit evil. If anything I'd prefer to receive error feedback and then send a reply back to say to update but by getting that error feedback it means if it's something new then it could still be fixed for a newer version. The main issue then is about people not responding to such messages (sadly saw that too often with the Winamp betas - especially those on ancient public betas - which is why I want to try as best as possible to prevent a similar scenario when it comes to WACUP usage).
-dro
-
I'm full of bad ideas. It's my trademark.
They're not bad as you've explained things and those reasons make sense based on your needs / requirements. The main thing I'm taking is a lot of good comments in general in the responses along with explaining why it could be the way to go rather than just "do it this way" and leaving it as that.
-dro
-
Is a tricky one... my preferences would be:
- No auto update without user's consent (but it could have an option to set it like that)
- No expire date (as Pawel said: "There may be resons that user stick with specified version") * .
- Do warn there is another version when it comes out and / or at certain periods of time (every 2 o 3 weeks, etc -with option to turn this warn off-).
* Besides, giving the option to the user to update or stay (because of x issue implemented by a newer version), can leverage the developer of having to consider a EVERY POSSIBLE scenario and focus on the most important issues / bugs.
At least if I get things wrong it wasn't just my decision as the rough ideas I had in my mind would have needed some tweaking based on the feedback received so far :)
The one thing that is floating around my mind is whether trying to keep things ok for all is going to possibly make for a more complicated settings page for the updating options than would be done. As the native option was just a check box, a window that appeared and it required manual interaction.
Whereas I can already envisage a few checkboxes (for overall checking and sub-levels) and a few dropdown options (for update intervals or how to handle a new update) but then on actually trying to implement things it might slim down to not much (I think I'm possibly over thinking things at the moment).
At least having the overall update action on by default (if only to notify of a new update) seems to be a general consensus so far.
-dro
-
if you don't update in that two weeks, then the version you are using is disabled.
Very bad idea!
I'm full of bad ideas. It's my trademark.
I think you are not. You have got plenty of great ideas, don't you?
And one (disabling WACUP without user approve) not so good :)
-Pawel
-
I think Betas should auto-update, but the stable versions should backup any replaced files if they do not wait for interaction.
Unlike the increasingly common habit for keeping people in the dark, I think you should make a point of showing the updates, versioning and progress, so that even in full-auto mode users are kept in the loop.
-
My 1 Cent:
1. Notify User that an update is available.
1a. Show text of notification of what is updated
1b. Version and info
2. Slipstream the download (w/ option to disable)
3. Load new Version || Ask To Be Notified (Updates)
:)
-
I think there should be atleast notification for update and link to update.
For myself I would like auto update. Though that could be disable from options.
-
I think every so often that the way to keep winamp up to date is for the users to report on bugs with the current version, and with the feedback from users fix the issues with an updated version of the software.
-
My preference would be by default to show a notification of an update with a "skip this version" option. As an option, allow for do not check for updates. Never force a new version upon a user.
-
IMHO, Beta should not have auto update. It is for testing purpose and testing only it be until the full version is released. Clean install for release version.
-
IMHO, Beta should not have auto update. It is for testing purpose and testing only it be until the full version is released. Clean install for release version.
How would beta testing an auto update feature work if you don't have it in the beta to test it ?
-
IMHO, Beta should not have auto update. It is for testing purpose and testing only it be until the full version is released.
There's arguments for both sides of whether to auto-update a beta build or not but seems to be more so on the side that it's ok (with opt-out) for betas and then the opposite for release (opt-in by default). But when it comes to betas, having things kept on a recent set of builds is more beneficial and is why the potential to auto-update a beta (within reason) is more appropriate and is part of the reason why the beta builds eventually expire as a build from october 2016 is no use to me to get feedback about when we're into builds from april 2017.
Hope that makes sense and whatever is finally decided upon (which I'll need to work on it sooner rather than later) will within reason allow for opting out but the expiry nature will be maintained for the beta builds due to my reasoning above and by agreeing to beta test builds I hope it makes sense why such things are done (if only to try to make things a bit easier for me).
Clean install for release version.
This is an interesting comment as I can see both sides of the fence when it comes to that point. Yes it's probably better to have a beta and a release install (for when we get to that point in time). However as WACUP becomes more mature I can also see the need to have separate installs being less important so one install that's used for everything could be feasible (which is how one of my dev+test build installs ends up being) since sometimes real usage can show up things that don't happen in a specific 'clean' install.
I've made my suggestions to the beta testers for the time being that it makes sense to install WACUP separately to any existing Winamp install but as the overall aim is for it to be able to be installed over the top of an existing Winamp install and 'just work' then there are going to be times where a clean vs separate install setup isn't going to help when it comes to the testing of things. Plus as everyone likes to do things in slightly different ways, that variety in how installs are done has been helpful (especially in the earlier WACUP beta builds) to catch issues that wouldn't have been seen until much later in the development phase where the changes that were needed would have been more painful to make compared to when they ended up being made.
But definitely how to test things is an interesting area of topic and as 100% coverage is impossible imho, sometimes just doing what people naturally do often works out the things that wouldn't be found via a more formalised process (which itself has it's benefits).
-dro
-
My preference is like what Valve or other companies have done.
The steam like version would be that a popup would come when a new version is available with a changelog attached to read and two buttons(Install/Update or close)
A worst example is blizzard with the battlenet app, where you get a popup on when a new version is available. You can press install or close. if you press install it updates it. if you press close the programm shutsfull down.
Or another prefered way of mine is what Mozilla had done. A use time check like above companies did and a self check for updates under the about window.
----
In the end it is a hard question to solve since you can't make everybody happy with it. Some would like to check the developers site for new updates to install. Others would like to have an auto check.
Even others would like to have a full installer which is making a full install everytime.
-
I like the auto update feature with the options of:
a. check box - automatically check for updates to Winamp.
b check box - enable silent background updates.
Works fine for me.
-
I have no preference whatsoever.
-
No preference is a preference ;)
-dro
-
Auto-update has value. Have a current version, and keep a previous version as backup.
-
To be honest, I hate 'auto-updates' .. all of them :')
But in this case I think the trust I have in your opinion on this (what would be best for the project) is big enough to set those anti-feelings off.
Other option would be to let the user semi-decide. Like automaticly downloading the update enabled, and actual setup when user wants.
-
Ok, so I'm finally getting around to doing this and the following seems to fit with the majority of views (thanks to all who chipped in):
Update mode:
Auto (now / on close) (default = on close)
Prompt (yes / no prompt + info shown) (default)
Never (not ideal but done for those who might)
Frequency:
Daily
Weekly (default)
Fortnightly
Monthly
Installer Options: (used when not running in auto mode - for auto-mode it'll just run the install as "No interaction")
No interaction (effectively silent / auto)
Some interaction (skip most pages including directory selection & post-install skin selection - just basic pages & custom selection) (default)
Full interaction (manual install)
As a first spin I think that covers most of things that have been raised (will post a screenshot of the page once I've done that). The one thing that I'm not going for is allowing the non-auto mode to pre-download the installer as that is at odds with not wanting to use an auto-update solution.
-dro
-
Attached is a screenshot of the options I'm implementing along with it being in the default states choosen based on your feedback.
Feedback, etc are still welcome whilst I'm still coding this & making some additional installer changes to better fit in with the modes needed (as silent install testing hasn't seen that much testing done on it).
-dro
-
Well that didn't take long, attached is a revised version based on feedback via discord (thanks all for being quick on this!).
The frequency update option has been moved to the top of the group so it doesn't seem to be related to the 'never' option & some of the wording has been tweaked to avoid confusion & provide better clarity (primarily for the installer options section).
-dro
-
Attached is a screenshot of the options I'm implementing along with it being in the default states choosen based on your feedback.
Feedback, etc are still welcome whilst I'm still coding this & making some additional installer changes to better fit in with the modes needed (as silent install testing hasn't seen that much testing done on it).
-dro
I think it's most perfect now, it will fit every user's needs. I'm looking forward to some new testing. I'm planning to do double-testing; one installed winamp and one running portable on a external thumb drive. I'm planning to test it among with 10+ plugins (some most forgotten by most.. :))
-
Here's some final screenshots for the update features (which are a bit newer than what some have seen in Discord whilst this has been worked on).
The beta_prompt.png is self explanatory and is what will be shown on loading if the default 'prompt' mode is selected.
The beta_download_code.png is the alternative way to get an update as well as showing something beta testers will need to do to allow for the updater to automatically work. For non-beta builds (which getting this done is a big step closer) it will not have the 'beta download code' section. Additionally to go between beta & non-beta builds will require manually installing the appropriate installer to opt-in/-out of that mode as needed (i.e. final builds only update to final builds).
The final one, beta_download_pending.png is what you'll see if there's an update and you've either skipped it or just haven't gotten the on-start-up notification yet (depending on your update frequency checking options).
Overall I think I've now got an update solution that should be tolerant enough for poor network / site issues as well as not being too nagging in nature and simple enough to update :) As this work has involved the WACUP core along with server side and installer changes to help slip-stream things (it's possible to do 3-clicks to complete the update under the default settings which I don't think is too bad).
-dro
-
Now that beta builds 2740 and newer have updating support (with 2800 hopefully resolving all issues related to it) I'm going to un-pin this thread as I think we can call it as a done feature. Thanks to all who contributed in the suggestions & testing of the the update system.
-dro
-
I would prefer for the application to check for updates and simply have a pop up window that allows you to either update the application and restart or ignore it and do it later by manually going to the website and getting it.
There should also be a checkbox in the settings to enable checking for updates and for auto-updating on startup. but neither should be enabled by default.
-
The first part is how it now works -you get a prompt that you can agree to & it downloads & runs the installer or you skip & you can update it yourself or on the next update.
With the second part, it was decided to have it checking for updates (via the prompt method) on by default but auto-updating is not a default mode & has to be opted into (is shown in the screenshots in the prior few posts what the config options are & all of that).
-dro