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