From: Mirko H. <ba...@gm...> - 2009-01-29 10:45:00
|
Well, yeah, you're right, it only applies those who don't use the prepackaged version from their distribution. But I think there remain many others that use aMSN, too. And my thoughts were that our extra work (for creating all the different versions for a complete release) would decrease, because creating an autoupdate would work almost the same way as our plugin updater works, it could be automated and so a lot faster and easier, not only for us, for the user, too. That are two good things, and IMHO it's very important to have bug fixes fast available for the user. When there are some annoying bugs that were fixed in the SVN directly after the release and the next bugfix release will be released 3 months later, we have unhappy users for 3 months. What the distros do in that case is not our problem, but those users that depend directly from us and our releases are happy to get their bugs fixed as quick as possible. So then why not being able to fix those bugs in "realtime"? I see the point on linux and several other unixes with the rights and of course the decreasing number of visitors on the website, but maybe we could find a better solution. Then how about always showing the user a changelog on our website after having autoupdated? It will always open the website, so the user has to see the ads (and maybe click it). Or we create some kind of "patch package" that needs to be downloaded manually, and the user only gets notified about it. Note: The difference here is, that such a "patch package" could be created by an automated process, we don't need the whole team to create all those packages in different formats. It's a package that is valid for all OS. We only need some addition that is able to extract that package, maybe verify, and then patch the files. That's all. If you say it's unnecessary, it's ok, I just thought it would be a good thing to increase the satisfaction of the users and give us the possibility to distribute patches easier and faster. 2009/1/28 Youness Alaoui <kak...@ka...> > I'm not sure it's a good idea.. adds extra work for us and is pointless > really.. if someone needs to update, he should just update and that's it... > also note that all distros disable the checkforupdate stuff so it would only > apply for mac/windows or users who compiled from source... also what to do > about the permission problems... what if you can't overwrite files... (a > solution would be to have the whole procs that were modified inside a file > and source that file at startup from $HOME, it would overwrite the procs > body in memory). > > I think people should just download the new version and that's it, all the > rest is a problem of lazy users or lazy distros and that's not our problem. > I think we should concentrate on other stuff... > > p.s: also, the more we release, the more traffic we get, which is always a > good thing if we want to think about the revenue generated by ads... > > my 2 cents.. > > KaKaRoTo > > On Wed, Jan 28, 2009 at 12:22 PM, Vivia Nikolaidou <vi...@ee...>wrote: > >> >> On Wed, 28 Jan 2009, Mirko Hansen wrote: >> >>> >>> In theory we could only deliver patches and add a binary of >>> "patch" to the package for those OS that don't have patch in >>> their repository by default. That would be the perfect way to >>> distribute the patches. >>> But my original idea was to keep on merging the changes in SVN >>> from trunk to the branch of the release, and there make all the >>> modified files, since the release, available for the auto >>> updater. Maybe compressing them in one file would be better to >>> keep the load of the server and the traffic low, but I think >>> there shouldn't be any problems as long as we pay the same >>> attention on what updates we offer for autoupdate as we do for >>> a normal release. >>> >> >> Good idea. It would require modifying the autoupdater but it´s certainly >> doable. If everyone agrees, and if you are willing to work on it (because we >> are low on resources), we´ll TODO it. >> >> Vivia >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Amsn-devel mailing list >> Ams...@li... >> https://lists.sourceforge.net/lists/listinfo/amsn-devel >> >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Amsn-devel mailing list > Ams...@li... > https://lists.sourceforge.net/lists/listinfo/amsn-devel > > |