Am Mittwoch 27 Juni 2012, 17:21:28 schrieb Michael Jansen: > > This is partly still under discussion. > > > > However the currently implemented solution is that each framework has a > > versions number, but that version number can be upgraded in all > > frameworks at the same time, using a script. > > > > A future framework on top of all others, could provide the version number > > for all apps, much like the current kdeversion.h. Basically it would be > > the "SC" number, and not the version number of the libs themselves, as > > is currently the case. > > But that SC number would be a lie. Because you only assume all modules are > installed in the versions that were release as SC X.Y . You have no idea if > the user or distro uses older or newer versions for some libraries, modules > or apps. So that number has no information value. Perhaps some marketing > value. But in bug reports it is useless.
Right now, in Gentoo we're basically relying on the fact that all kde sc packages that are installed have the same exact version (modulo local Gentoo revbumps with patches). However, this is not a "must". If you want, you can give each and every small component of (what used to be) KDE a separate version number. But... *before* you do this, you'll need to define exactly what dependencies you will require across the *entire* software set, taking into account version numbers! Right now, if someone installs (on Gentoo) gwenview-4.8.4, this pulls in as a dependency libkonq-4.8.4. Now, this is likely overspecified, and we might be fine with libkonq-4.8.*. So, a general rule for the moment may be gwenview- X.Y.Z requires libkonq-X.Y.*. Now, please give me the specifications for the new version numbering first, before you start using them! In particular also... what are major, minor, bugfix releases, what do you want to enforce in a dependency freeze, ... Cheers... -- Andreas K. Huettel Gentoo Linux developer [email protected] http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
