Release Team BoF Summary

[David Faure]

On Sunday 15 July 2012 01:00:28 Rolf Eike Beer wrote:
> Am Samstag 14 Juli 2012, 23:47:29 schrieb David Faure:
> > On Saturday 14 July 2012 12:29:57 Michael Jansen wrote:
> > > Why not marking an alpha, beta and rc as what it is and every other
> > > project
> > > out there already does? Why masking is as a stable release?
> > > 
> > > 4.N.1~alpha1
> > > 4.N.1~alpha2
> > > 4.N.1~beta1
> > > 4.N.1~beta2
> > > 4.N.1~rc
> > > 4.N.1
> > 
> > This is fine in external communication and bugzilla, but we still need a
> > value for KDE_VERSION_MAJOR, KDE_VERSION_MINOR and KDE_VERSION_RELEASE
> > (see
> > kdeversion.h[.cmake] in kdelibs).
> > This is necessary in order to be able to write
> > #if KDE_IS_VERSION(4, 9, 82).
> 
> I thought about this, too. But then I wondered: do we really need this? Why
> would we check anywhere if this is e.g. beta2? What if all versions since
> beta1 (alpha1? rc1?) internally say they are 4.10.0 as number (for bugzilla
> they should indeed use their string version, but that's another story). Who
> would need to distuinguish between a rc1 and a final release component
> (beyond bugzilla)? Since the API must be the same anyway, and working
> around certain behaviour of a rc1 compared to something else is bogus also,
> no?

You're assuming we never add API in order to fix a bug, between e.g. alpha2 and 
beta1. This has happened in the past, though. I don't see why we would want to 
remove this flexibility, which allows to not break compilation (of the 
application) when using a very-recently-added API. Not a huge deal, but it's 
convenient.

Of course with KF5 this will be about the "frameworks version" rather than the 
"kde sc version" but the core of the discussion about version numbering is the 
same.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5