On Friday, January 7, 2011, Frank Karlitschek wrote: > On 07.01.2011, at 01:47, Aaron J. Seigo wrote: > > On Thursday, January 6, 2011, Frank Karlitschek wrote:
> Introducing custom parameter kills OCS as a standard because this means > that not all clients can talk to all servers. which actually isn't relevant in this case. > And I don´t really understand why because it is absolutely no problem to > work together with the other server and client developers and put it into > the official spec. it isn't a problem. i just don't want to waste anyone's time (including my own) working through a standardization process for something which we don't know how well it will work in practice. > > the lack of a well-defined version # scheme is moderately troubling, but > > i'm trying hard to ignore that as a source of possible edge cases ;) > > Perhaps it´s not complete clear in the spec but there is in fact a system. > We discussed this with the MeeGo and Midgard guys during academy. A higher > number in the version field means a newer number which is than offered to > the user as an update. The version field don´t has to be the real version > string like "KDE 4.6 RC2 patch 17" it can a random number. It just has to this is precisely the issue: it isn't well defined so it can be "4.6 RC2 patch 17". amarok's got a cute little "version number parser" that assumes an "x.y.z" style approach. this really ought to be specified in detail in the spec so that systems can be reliably built around it. > be increased to push a new version to the users. This is how it work in > the new MeeGo Installer for example. Cou could just use the git revision > number in the version field and your done. git uses commit hashes, not revision #s, so i'm not sure if this would work to well in the case of git. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
