I agree with Roman that it's good to have some kind of plan or roadmap, feature or date driven. Personally, I would like to see regular releases, even if they contain only minor updates. If big feature implementations would block releases, we could consider developing them on feature branches.
Greetings, Marcel On Jan 10, 2013, at 14:32 PM, Sascha Zelzer <[email protected]> wrote: > Hi, > > First, congrats to the release! > > Regarding the release policy, I made a few comments below. > > (just my two cents) > > > On 01/10/2013 01:29 PM, Alexander Broekhuis wrote: >> Hi all, >> >>> As far as I know we don't have a release policy yet, although I think this >>> will be beneficial for Apache Celix. >>> My personal preference would be date driven releases, but I am curious what >>> the rest thinks. >>> >> In the thread mentioned by Pepijn I already state that I do prefer to use >> Jira for issues. >> >> Regarding a release cycle, I actually don't prefer a date driven cycle. >> Why not? >> * We currently don't have many users/committers relying on releases >> * The committers have little time, so keeping a planning will be really >> difficult >> * Making a release to satisfy the schedule feels wrong to me, we either end >> up having releases with half-done/half-broken features. Or we end up with >> quick/dirty solutions for features. > From my experience with working in a larger open-source project, I tend to > prefer date-driven releases, *if* the daily development is not done on the > main code line but in feature branches. Our recent switch from a > feature-based release cycle to a date-driven process was highly beneficial in > terms of visibility, community growth, and confidence in the project. > > Previously, releases did happen very rarely since there was always someone > who wanted to put yet another feature into the next release, leading to more > bug-fixing and testing. For a smaller development, this might not be a > problem. > > What's more is that the date-driven process based on our master branch took > away the "excitement" of "releasing something" which turns out to be a good > thing. Making a release just means taking a snapshot of the master, fixing > critical bugs for a fixed time-period and then the code is just released > after all tests run successfully, documenting the remaining bugs as "known > issues". > > Best, > > Sascha > >> >> I prefer a feature driver plan, and the outline in [1] was a first attempt >> of me to get a feature list. >> >> What I do like is to have a release more often. So while the list has >> several items, I don't object releasing if one or two items are done. But >> we should keep in mind that making and voting for a release also takes >> quite some time. There are some incubator project trying to release 2 >> weekly, imho this just isn't viable. A new release is already due while the >> previous one is not yet available. >> >> >>> There has been a discussion on what should be in the next release [1], but >>> we have not yet discussed a date. >> >> At this moment I don't think it is possible at all to discuss a date, at >> least, not for me. All my Celix work is done in spare hours etc. So I can't >> commit to that much at this moment. A feature driven release is no problem >> for (as stated above). >> >>> >>> [1] http://markmail.org/message/5zhfugurztlaha6d >> >> Any other ideas are welcome of course! >> > > >
