Discussion of general topics related to the new version and its place in the world. Don't discuss new features, report bugs, ask for support, et cetera. Don't use this to spam for other boards or attack those boards!
Forum rules
Discussion of general topics related to the new release and its place in the world. Don't discuss new features, report bugs, ask for support, et cetera. Don't use this to spam for other boards or attack those boards!
The lessons that were learned are:
- New major releases must have a smaller number of feature-set changes and be released more often.
- To the maximum extent possible, feature-set changes should be isolated from each other. (This implies that some development must take place outside of the main tree and only be merged in when it will not destabilize other simultaneous development.)
- Major releases should be targeted at a time deadline rather than a feature-set deadline. If some feature is not ready in time, then it should be disabled by default and left for the next major release.
Interesting take on the whole issue, really,a nd well worth reading if you plan on running a non0linux *NIX boxen.
actually I think this is a very interesting issue.
when I saw the list of things to be done in the community coding project, my first thought was 'wow - that's a lot'. no wonder olympus isn't any where near a release when so many things need implementing.
i think reducing the list of features into olympus and focusing on a few goals would do phpBB some good. shorter release cycles are definitely A Good Thing (TM) for any open source project.
however, I think the community coding project is an excellent idea, very open-sourcy and well thought up.
The features open for the community coding project are not considered being integrated into 3.0 as a must. If it is finished by then and feasible, then it be integrated (of course we target this effort). But if not, we will consider them for 3.2.
