Release Team BoF Summary

[Michael Pyne]

> On Monday, July 16, 2012 22:37:24 Michael Jansen wrote:
> > > I do not like maskerading pre releases as stable version. Version
> > > numbers have a
> > > clear semantic meaning. And KDE currently breaks that.
> > 
> > We break what? Our numbers have a clear sematic meaning, i can look at a
> > version number and tell you what it is. Agreed it's not trivial, but 
saying
> > our numbers don't have a semantinc meaning is not true.
> > 
> > Cheers,
> >   Albert
> > 
> 
> Any version numbered minor.major.patch is a stable release. That's what we
> are breaking.

Internally there must be a major, minor, and patchlevel number assigned and 
"4,5,71" is certainly more descriptive of what's going on programmatically 
than leaving it as something like "4,5,4" (and to parrot what dfaure has said, 
I've also seen code take good advantage of API added after an alpha release).

If we want to call the corresponding "named version" (in git, tarball name, 
website, etc.) something like 4.6.0_alpha1 then that's fine and great and all 
but we can't dump text into our KDE version macros so we still must have a 
mapping for it.

I see in your email from yesterday that you propose an automatically-
maintained header-only increasing build number (which could possibly encompass 
snapshots as well)... is this internal-only build number really to keep the 
'purity' of the internal-only patchlevel version? Because that really just 
seems like a needless change, especially given the large corps of people who 
are already quite familiar with existing KDE practice regarding internal 
version numbers.

(P.S. Does anyone know how to configure KMail to reply to the plain-text 
version of an email instead of the HTML rich text version? :)

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120716/be38002f/attachment.sig>