Release Team BoF Summary

Sun Jul 15 14:31:37 UTC 2012

El Diumenge, 15 de juliol de 2012, a les 16:25:23, Albert Astals Cid va 
escriure:
> El Diumenge, 15 de juliol de 2012, a les 14:06:32, Jorge Manuel B. S.
> Vicetto
> va escriure:
> > -----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
> 
> You mean
> 4.11.71 -> 4.11.72 -> 4.11.81 -> 4.11.82 -> 4.11.83 -> 4.11.90 -> 4.11.91 ->
> 4.12.0
> 
> Right? going back in numbers (as you go from 4.12.90 to 4.12.0) would feel
> extra weird to me.

Oh, i see you already corrected yourself in another mail.

Cheers,
  Albert

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