KDE 3.5 Alpha will be tagged in three days and many applications in /branches/KDE/3.5 still show the version number they had in the 3.4.0 release. 
I usually go trough all modules before releases and look for many applications whether there have been changes since last release and if the version number has been already increased. This is time-consuming and I don't feel that I should be doing it. Please maintainers of applications (or as fallback contributors to) increase version numbers regularly!
Without proper version maintenance you have additional effort to categorize bugs or callback bug reporters. Don't expect users to add source package information themselves or them having the same kdelibs/kdebase version installed as every other module. For proper bug management you have to also ensure that Bugzilla knows the versions for your product: add it with the Edit products link. If your account has not the necessary rights contact me and I will either add the missing version or give you the rights.
How does a good version number look like? It doesn't have to match the KDE release number. Something in the form of x.y.z where z preferably matches the KDE release revision (nice to see if a version number has been already increased) and at least y being increased for every feature reelase. For the lazy ones (and if you don't mind matching your application version number the KDE release number) you can use the KDE version string as application version. Bad are version numbers which are not changed at all, maybe even for several releases (bad example: kwin).
On a related note, it's disappointing how few maintainers collect and list changes for the release notes of bugfix releases. There are several modules with no or only a short list of bugfixes but a longish 'all SVN changes' dump near by.
Syndicate Blogs
Suse
On this subject, someone should tell Suse to stop releasing amaroK with versions like 1.2-CVS. It makes bug reports difficult like you said.
amaroK has a good ChangeLog. We just update as changes are made.
changelog autogeneration
sooooo, where's that script that was supposed to go through all the commits with BUG or FEATURE in them and pull them out for the changelog?
That's a lot easier than us maintainers having to go through the commit log, find bugs that were fixed (which is easier thanks to the new keywords), look up the relevant information from bugs.kde.org and then fill out the entries in the changelog.
Also, just thought i'd point out that if you keep going through and incrementing version numbers for us, we maintainers will never do it ourselves. Why should we bother when we know you'll do it anyways?
Re: changelog autogeneration
> where's that script that was supposed to go through all the commits with BUG or FEATURE in them and pull them out for the changelog?
IIRC Waldo has one or wanted to write one. I now only care about the complete change log dump (as help for maintainers).
> Why should we bother when we know you'll do it anyways?
The intention of this blog entry is that I don't will do it anymore.
And I only did it for the major applications (like KMail/KOrganizer/Kontact) anyway.
Also I will not, or can technically, update every application homepage or kde-apps.org/Freshmeat record after a release.
where's waldo? ;)
> IIRC Waldo has one or wanted to write one. I now only care about the complete change log dump (as help for maintainers).
Time to find waldo then, i suppose.
> The intention of this blog entry is that I don't will do it anymore
cool! I'll be sure to update the version for my application then. hmm, perhaps a checklist for application maintainers would be helpful here...
Checklist for application maintainers
Like Maintainers' Release Duties? Yes, this topic is not new. *sigh*
maintainers' release duties
doh, you just provided another reminder that i still have to do seperate tarballs for Kopete so that people with KDE 3.3 don't feel left out.
(i have it written down, but well, sometimes that doesn't work so well)
You triggered quite some changes in the ChangeLog...
I just added this file:
http://www.kde.org/announcements/changelogs/changelog3_4_2to3_4_3.php
But the .txt-links are not working as I don't know how to create those files. Can you please have a look at them?
svn2log.py
> But the .txt-links are not working as I don't know how to create those files.
I used svn2log.py which is a slighty modified version of the original to be found in the Nemerle repository.
> Can you please have a look at them?
But I will only run it once the release is tagged.
Auto-generated logs
Oh, no. The auto-generated logs are no replacement for a proper list of changes between versions.
Has anyone bothered to look at the output generated? It borders on the hilarious. Some message commits are so short they don't make sense, unless you know the context.
for use as a basis?
But could they possibly be used as a basis? Even if I just had a list of bugs that were fixed on the branch between the tagging of releases that would help. Perhaps I can get this myself with a little bit of svn log and some grepping.
My problem with updating the changelog is that none of the other developers keep it up to date, and to sit down and do it is a long and sometimes tedious process. i think it's time to craft a script.