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 <kakar...@kakaroto.homelinux.net>
> 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.auth.gr>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
>> Amsn-devel@lists.sourceforge.net
>> 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
> Amsn-devel@lists.sourceforge.net
> 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
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
