> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
