-----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 [email protected] > 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 [email protected] https://mail.kde.org/mailman/listinfo/release-team
