Release Team BoF Summary

Sun Jul 15 14:25:23 UTC 2012

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.

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