On Sun, 26 May 2019, Matthias Klose wrote: > >> In general, I think it would be helpful for our users if we uploaded the > >> prereleases to experimental but stuck to GA releases for unstable, > >> testing, and backports. I think it is easy to mistake, for example, an > >> 11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being
It would help if prereleases did not use the ‘+’ character. Perhaps an upstream mangling in debian/watch to replace it with ‘~pre’ or ‘~ea’ or so might help? > >> distributed by other projects. > > I would like to avoid experimental, because it really doesn't get much > testing. What about using unstable/testing/stable-backports for preleases until the soft (not hard, so we have some time) freeze, then tracking only releases, so a frozen testing, stable-backports during time of the freeze, stable and oldstable-backports have releases only? > See the openjdk-11 updates as a stable release branch, and it's worth to > check That’s a good argument against the previous paragraph, and it matches what I wrote earlier in the other thread: | actual release or something newer): when an upstream branch | is considered to be comprised of only security and critica | bug fixes, the releases upstream cuts off that branch are | just snapshots at some given point in time, and a prerelease | would be just as stable, as surely upstream would only have | applied a patch to that branch only if it addresses either | a security problem or a critical bug and it had already been | tested in the latest development/feature branch. (Does this To me, this makes just as much sense. Perhaps, shipping upstream prereleases really isn’t a problem (trust the content, not the label), but labelling them clearly (see the above comment about an upstream mangling rule in the watch file) might please all but the weirdest (that Azul guy) people; after all, if it’s really a fix-only branch, it’s in the interest of our users to get the fixes out fast without waiting for an upstream release (possibly). > these out early, because upstream doesn't test most Debian architectures. And that’s a good argument in favour of packaging them up for unstable and testing them there, widely (especially as some of the ports architectures’ buildds don’t often get around to building experimental). bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ********** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **********
