Mike Mestnik transcribed 784 bytes: > This is great, there are several issues I had working with GNUNet that > existed entirely because there were no current releases. > > There are a few things to consider above simply having regular releases and
I've had my doubts about this in the beginning (slow release cycles), but I don't think it's bad. The expectation to release very frequent is nothing new. And it exposes some weird "productivity" view on work. Of course not having something like bi-anual releases is not good when breaking changes are introduced. We should at least have a significant portion of the network use the last stable release. > that's handling changes that are incompatible with previous releases. I > would wager this will make LTS releases impracticable or impossible. I think LTS without the S is possible, in theory old versions of the network continue to work as long as people use them. They just need to be available in the Operating System used as packages for downgrading, upgrading, etc). But for support, I don't think we could manage supported LTS releases at this point with a team this small and on volunteer time. It's something I see worth doing (support for longterm versions of the network) when someone comes up with an idea/rfc how this could work out for volunteers. I imagine official "L"TS for ~12 months or something like that. > Things to consider for a new release are API changes and of course protocol > changes. The project ideally would avoid making ABI changes while not > making API changes. I would hope that adopting release goals would make > out of tree applications easy or easier to maintain. > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
