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
