Release Team BoF Summary

Sun Jul 15 14:06:32 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-07-2012 11:57, Michael Jansen wrote:
> 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).
>> 

<snip>

> 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

I provided specific numbers before to make sure we were all talking
about the same - from the above I see we are not.

When you start working on the hypothetical 4.12 release, after
releasing the 4.11 release, we (Gentoo) are fine if you use one of the
2 following schemes:

4.12.71 -> 4.12.72 -> 4.12.81 -> 4.12.82 -> 4.12.83 -> 4.12.90 ->
4.12.91 -> 4.12.0

4.12.0-alpha1 -> 4.12.0-alpha2 -> 4.12.0-beta1 -> 4.12.0-beta2 ->
4.12.0->beta3 -> 4.12.0-rc1 -> 4.12.0-rc2 -> 4.12.0

So, can you please use "-" and not "~". The "-" character has a
special meaning on versions for us. The "~" character can cause issues
for us, as we use it when specifying dependencies on other packages as
a "fuzzy version dependency".
As this is going to be the 4.12 release, please label it 4.12 and not
4.11.1* (4.N.1).

> 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)

We (Gentoo) try to follow upstream version numbering, whenever
possible. Having 2 different release numbers for the same package will
only cause confusion for us and or our users.

> 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.
> 
> 
> 
> _______________________________________________ release-team
> mailing list release-team at kde.org 
> https://mail.kde.org/mailman/listinfo/release-team
> 

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQAs5oAAoJEC8ZTXQF1qEPAXEP/2R17JVcntI+WxtlsmTCVQ5X
VzHIKs77qjz5aPuQML+MA8k4LDvJXXW7jCCMEgLwgZxebHiYzdPhmX5QvvtGZsJ3
nmKPtwkSze0R2vyTi+9SjLfCNJe0U/Qg2EKf7LdrNlaZvQU9tGn38QVIIqU8QzPr
Icdxyjo33cyVe0pTcBuzv2UeznPZd2N3QGPFtWHdDpDpMQE0cX1WHdaENb/Ls4Uo
oizSoVoNYCUHFpmou49pvLsy9QZ5JNUSYuHzJzdUDmeYsHRIte3Cfz31EdmxrZy7
1JIloqLPl1qdLsr6lOP7fgv6dJ6hgg60zWX76zmWjEVjW665GkTeQfR83dM6GQ6v
1+cDjoIh2NhRkHmgdghD2qEyg7ARjsGwZUP7k47pQ+8ll5wjaG1UwB8MRz7ZAwbi
3vvWvgL/73EZXGOr1tATVF1020/8pucHv7XCIfilHCIhuqqdmoih4hLvWxpzFuAK
PzbSMKOm0ihH3AjDF7wiogaRllQW+ycMJDr7MKUi71fW20Rrm7ihkcRm8AkOxzdV
TLFYcklCP6iAjI4xwiG1rii05axrg70m/e8c9TvhJxURLt7+GIC4My169lDZO5e5
nI2VN3EFJixm//EQTxs0q5jc6iIWlenn1Bgj2CwcxTmiG0Zr+gaMTb71zzBTBDrB
CVGzgbekrCq5OmWaieZk
=V6Me
-----END PGP SIGNATURE-----