----- Original Message ----- > Hi all, > > I'd like to start the discussions and some brainstorming for how we > could continue development going forward. This will be a bullet list > for > now, once we've discussed, I'll capture all this in a few Wiki pages. > These items are just ideas that have been brewing for a while, and I > don't want to risk losing them due to my ageing brain going mushy. > > * We aim for 6-month release schedule for major stable releases.
+1 for time based. More to that, but we followed that philosophy with -unstable already: Release often, release early. > This would put us around mid-December for v3.2, and June 2012 > for > v3.4 (or 4.0, depending on what we schedule in for feature > changes, see further down). > * We need a much better project plan for these stable releases. > I'll > start the work on the v3.2 plans on the Wiki asap. What I'd > like > to see is three main sections, like > 1. New features (this has to be a reasonable list, and > probably > no more than 1-2 major feature per core developer / > team). > 2. Major bug fixes (this can be a bigger list, but still > achievable). > 3. Incremental fixes as deemed necessary (bug reports, > crashers > etc.) > The Wiki will obviously be open for everyone to participate > with > ideas and additions. > * I'm hoping that v3.2 and v3.4 will be much less painful, and > much > less risky, to finish and upgrade too compared to the v2.0.0 to > v3.0.0 cycle. We definitely need to add a few more features in > each relaese, but perhaps with much more focus on stability, > performance, and usability (ease of use, correctness etc.). Our > users probably will go crazy if they have to experience the > 3.0.0 > pain on every major release :). > * We should do incremental patch releases for v3.0.x as often as > necessary. This will not be driven by a fixed schedule, but by > what the community and our users decides are important to > release. > Obviously security bugs have priority as well. > * I'd like to suggest that we have a release manager for the > v3.0.x > releases. This doesn't exclude anyone else from cutting a > release, > and it does not change how a release is created and voted on. > But, > it will ease the burden of preparing periodic patch releases, > backporting patches, and overall "herding the cats" to get > things > done for a release. If this is agreed upon, we'll start a > different thread on this topic, and if you are interested in > taking on this role, please post. I would like to volunteer as RM for the 3.0.x branch. Obviously, I'll need a little bit of support to get started, but I'd like to give it a try nonetheless. > * Documentation, we need to get this stabilized, and to the point > where any code changes that also requires doc changes should > all > be done together (i.e. no separate bugs thrown over the magical > doc fence). +1 Further down the documentation line: In our ats-cms branch I've already created a /trunk/ folder. Even though we've branched off 3.0.x, I don't think it makes sense to branch the docs - yet. We should get them ready for broader consumption, ASAP. Then we can and should branch. > Please discuss. > > -- Leif i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: [email protected] URL: http://brainsware.org/
