Version: (using KDE KDE 3.5.6) Installed from: Compiled From Sources This is at least the second time that KMail reset my custom toolbar configuration on a patchlevel upgrade (3.5.5 -> 3.5.6, 3.5.4 -> 3.5.5). While it is a known fact that KDE eats toolbar customisations between minor (3.x -> 3.x+1) and major level upgrades (y -> y+1), a patchlevel upgrade is neither expected nor meant to inflict additional configuration effort upon the user. Therefore I ask the KMail developers to *stop* increasing rc-version numbers in the toolbar configuration xml-files to keep users from having to reconfigure their toolbar settings on each patchlevel upgrade again. With *stop increasing* I mean over the whole lifetime of KDE 3.5.x. Note that this bug report only applies to KDE 3.5.x, as for KDE 4 KXMLGUI is said to finally vanish/become well behaved.
Changing severity from major to normal.
*** Bug 150040 has been marked as a duplicate of this bug. ***
I don't see how this can ever be fixed. If a new action is introduced and placed into the menubar/toolbar, the RC version has to be increased, otherwise the action won't show up there. One can argue that there shouldn't be new actions in minor revisions, and that is true. However, this bug report talks about avoiding that in the future - therefore the bug report can never be closed. I close this one as INVALID because of this. If you see a commit which increases the RC version between minor versions, file a new bug report (before the actual release, of course).
It can be "fixed" as this bug is reported against 3.x *only*. Therefore, it can be closed after 3.5.8 at the latest, if no rc-version upgrades took place. So please don't close it now, but after 3.5.8 such that this bug doesn't fall off the kdepim developer's radar. Regrettably, KDE 4 still uses the rc-version upgrade scheme which makes this bug apply to KDE 4 as well. But I won't report such a general bug against KDE 4 for the very reasons you mentioned. For KDE 4, a more elaborate versioning scheme has to be implemented (will look into it later and will write a proper bug report with suggestions). Reopening. Please close *after* the release of KDE 3.5.8.
>Reopening. Please close *after* the release of KDE 3.5.8. Done. BTW, wasn't there a discussion on k-c-d about this? It is really a kdelibs issue in my opinion.
Am Donnerstag, 20. Dezember 2007 schrieb Thomas McGuire: > >Reopening. Please close *after* the release of KDE 3.5.8. > > Done. BTW, wasn't there a discussion on k-c-d about this? It is really a > kdelibs issue in my opinion. It is fixed for KDE 4. And yes, it's a kdelibs cause. But it's the kdepim developers who were most thoroughly increasing rc-versions even for patchlevel releases. I don't think KDEPIM will have toolbar/menu changes for KDE 3.5.9 therefore this bug should stay closed (otherwise, I'll reopen).
> It is fixed for KDE 4. And yes, it's a kdelibs cause. But it's the kdepim > developers who were most thoroughly increasing rc-versions even for > patchlevel releases. I don't think KDEPIM will have toolbar/menu changes > for KDE 3.5.9 therefore this bug should stay closed (otherwise, I'll > reopen). I can tell you already that when the enterprise branch is merged back into the 3.5 branch, the RC version will increase again. There is no way around that (but the merge would justify more than just a minor version number increase anyway)
*** Bug 157877 has been marked as a duplicate of this bug. ***