Release Team BoF Summary

[Michael Jansen]

On Sunday, July 15, 2012 01:00:28 AM 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?

I would second that.

But if it is reallys needed we could extend the macro with a fourth parameter. 
But since i do not think it is worth to map those alpha, beta string to 
numbers in that comparison i guess the best would be 
to just enumerate all those prereleases with a build number.

MAJOR, MINOR, RELEASE the same as currently. And add a build-number 
(internally, header only, automatically maintained)

4.N.1~alpha1          build #1
4.N.1~alpha2          #2
4.N.1~beta1           #3
4.N.1~beta2           #4
4.N.1~rc              #5
4.N.1                 #6

semver says to append the build number into the version with a +. But i guess 
in our case it would be preferable to do:

4.N.1.1~alpha1          		build #3
4.N.1.2~alpha2          		build #5
4.N.1.3~beta1           		#3
4.N.1.4~beta2           		#4
4.N.1.5~rc              		#5
4.N.1.6                 		#6

or to make the build number thing clear like this scheme

4.N.1+2~alpha2

That would even help with those snapshots we probably, perhaps will provide.

4.N.1~snapshot20120701          build #1
4.N.1~snapshot20120708          build #2
4.N.1~alpha1          		    	build #3
# This snapshot was done after the first alpha release.
4.N.1~snapshot20120715          build #4
4.N.1~alpha2          		  	build #5
...

The build number could help distros too that do not like those alpha, beta, 
snapshot, rc string. They could package

4.N.1.1 (first snapshot)
4.N.1.2 (second snapshot)
4.N.1.3 (first alpha)

And it can help us with the repackaging. Same revision. Different build.

KDE_IS_VERSION then could even check for snapshot releases.

Our distros could stop caring about alpha, beta, rc, repackage and just use 
MAJOR, MINOR, RELEASE, BUILD. The alpha beta stuff is only for the convenience 
to easily see what quality a packages has and should therefore be used 
everywhere where the version faces the user but the build number is needed 
there too).

But that only works if we decide to allow our package revisions to diverge. 
Because if we repackage one its version number will be different forever 
(because its build-number is one higher).

Mike

PS. Damn i really try to write short mails. I usually fail. But i try.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120715/0831e12d/attachment.html>