Hi, > I think, that it would make more sense to make a releasing process clear, make > it predictable. So perhaps rather start voting about that? So we could came to > some conclusion, release rules? That way we don't need to argue about this > anymore, it would be set in the stone, unless changed by another voting in the > future if we find out, that it doesn't work well. > > So this is my view for the start: > > * new release is branched automatically, 1st day of month, Y months after the > previous release > * release.0-rc1 images are being built immediately, automatically > * release.0-rc2 images + 14 days since branch, automatically > * release.0-rc3 images + 30 days since branch, automatically > * final release.0 images + 45 days since branch, automatically > * point release every 45 days, automatically > * point release immediately in case of serious issues like bricked > device, security fixes etc.
I'm not in principle against this, but wouldn't that mean that we either have mixed kernel releases again or would have to throw out a lot of targets for each of the stable branches (which might be always the same set of less-cared targets)? > > + claim official support only for one previous release, any other option > would need some kind of funding in order to have dedicated resources for > that > level of support, otherwise we steal this resources from other parts of the > project (one of still unresolved topics from Hamburg) This might also have negative impact on the "slow" targets, as they might quickly end up with no supported stable branch anymore (unless there are mixed-kernel releases again). Just wanted to add that perspective. Best Adrian
openpgp-digital-signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
