Greetings, Wietse Venema! > I'm reconsidering the once-per-year schedule for stable releases. > Basically, a Postfix stable release freezes development at a point > in time, forever. Primarily, this is good for stability.
> * In this day and age it seems archaic to have to wait for up to a > year before useful code can be deployed in a stable release. > * The once-per-year schedule makes development a race to get things > into the upcoming release, so that it does not have to wait for > another year. Reading your message, I only see a call for speakers. But I have a doubt you did not consider existing development schedules of other projects and how would they fit into your vision of your project. Well, lets talk about it. Given project maturity, it's a negligible chance that something fundamental, like config file parsing, would be changed. So, that leaves us with 1. New functionality. 2. New features. 3. Changes in existing feature set. 4. Changes in existing functionality. #4 seems negligible as well, as postfix rely upon existing standards. Now, what about long-term supported releases? They are useful for enterprises which could rely on a stable feature set for their dependent needs/services. But they also stall development somewhat. Different projects handle this issue differently. PHP is extremely backward compatible. The code written for PHP3 can be run on PHP7 with minimal, if any, changes. At the same time they are maintaining 2-3 versions in parallel when something serious is changed intenrally that warrants the split. LXC supports dual development model, they have a dedicated LTS release version, where no major changes are happening, and a mainline non-LTS version, which picks up all feature-complete innovations. So, what do you think would suit your project? -- With best regards, Andrey Repin Wednesday, January 30, 2019 22:00:26 Sorry for my terrible english...
