> > Personally, I expect every honest release to be a combination of the: > #1 general feel of the developer community that this particular set > of source code is 'good' > #2 a user community vouching for the fact that by and large it > satisfies their use cases > #3 developer/PMC community vouching for the fact that to the best > of their knowledge the bits that comprise the release are safe to > use from legal standpoint > #4 a signal to the downstream projects that they may latch onto the > new set of bits and expect them to provide a stable based for them > > I prefer a date drive release because of two reasons: - community growth: I expect a better visibility of the project if it has a clear set of release dates and I expect that a clear set of release dates will lower the threshold to participate in the discussion what should be developed in which release. So this should help for #2. - keeping pressure on the project: Even though we only have 2 committers with little time, or maybe especially because, I think is paramount that we have a always have clear release goal and date to keep some pressure on the development. Date driven releases will enforce this. I know for me this will help in planning some spare time for Apache Celix. Also for legal perspective (#3) regular - maybe small - release would IMO be better, that way we enforce that Celix has a periodic legal check.
As for a release frequency I was thinking about quarterly releases. So a release in March, June, September and December. That being said, I have no real problems with feature driven releases, _if_ we ensure we always have a clear date for the next release. Greetings, Pepijn
