On Tue, July 3, 2018 14:24, Michael Ströder wrote:
On 07/03/2018 08:07 PM, David Magda wrote:
It does not /have/ to be related to downstream distros. I mentioned the distros in my original message as a suggestion, and not as a hard requirement.
Then I fail to understand why you want that.
Perfect is the enemy of good. I think it's better to get the ball rolling on regular releases than doing a bikeshed on the exact timing.
I do not know what's involved in the release process, or how onerous it is, so will let the actual people that are going to do the work make that call.
If OpenLDAP has a biannual cycle, then the "out-of-date" release would only be at most six months old. Compare that between 2.4.46 to 2.4.45 (>9 months) to 2.4.44 (16 months).
Even then there's no guarantee that downstream maintainers really pick up the latest version at that time. No problem solved at all. And bear in mind that there are way more downstream maintainers out there all with their own release schedule.
Besides that Debian distribution or similar are way too slow anway.
Some of us don't have the time to pull down the latest git commit and roll our own release of OpenLDAP. If you need something more recent than what Debian offers that's something you can address yourself, but I would hazard to guess that the majority of people running OpenLDAP are using a RPM/DEB/etc.
Personally I'd prefer OpenLDAP project to return to the old release-early-release-often mantra. And hey, that matches today's *agile* CI/CD models pretty well. ;-)
If you want to argue for monthly or quarterly releases, I won't object. I also won't object to starting with annual releases. I just think there is something better than sleep(rand()).
-- David Magda