On Thu, Jan 13, 2011 at 2:51 PM, Inge Wallin <i...@lysator.liu.se> wrote:
> On Thursday, January 13, 2011 14:15:01 Cyrille Berger Skott wrote: > > On Thursday 13 January 2011, Tomas Mecir wrote: > > > As a disclaimer, I'm not active in Calligra development currently, so > > > my opinion may not be entirely relevant, but hopefully it will be > > > useful anyway. > > > > > > Wouldn't it be better to (at least for the initial release) use a > > > different development scheme with an alpha/beta version being released > > > every month or so, with no feature freeze in place? It could be more > > > work to manage it, but by maintaining a relatively constant stream of > > > pre-releases that each contains actual improvements (not only bug > > > fixes), you'd keep the general awareness of the project, while at the > > > same time having enough time to polish the applications to be end-user > > > ready for the first final version (2.4 or 3.0 or however you're going > > > to call it). > > > > One of my main concern with that is that I do think that having hard date > > gives us a focus. I think "a release when we feel we are ready" tends to > > make us go in many directions, because anyway we have time to fix things. > > While if you have a date, you have to focus on selecting what you feel is > > important to finish and fix before that date. > > That is probably correct. How could we make it so that we can keep focus > while still make sure that we get the necessary features and bugfixes in? > Perhaps by doing a suggested: every maintainer set a list of required to release features. Then we can set a fixed date for feature freeze and leave the release date opened. Pierre > _______________________________________________ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel >
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
