Well all sounds good to call for a freeze code and only focus on documentation and bug fixes, but I would not want to do just that until we've added a few widgets to the set.
A lot of users have been asking about the widgets and other stuff so I think we should add wigets into this release. I'm currently working on some widgets that were uploaded into cvs. These should be finished within the next three weeks. Hopefully by then we could then call for a freeze code. -- Raymond Irving --- Peter Romianowski <[EMAIL PROTECTED]> wrote: > Hi again, > > >>Well we made mention oh November but that's yet to > be > >>decided as we need to iron out a bugs and such. > > > > > > November seemed so far away back then ... now I'd > say no way by then. ;-) > > Maybe Christmas or New Years if we all really made > a effort with long nights > > and little sleep. :-) > > Sounds like the normal rule at the end of each > project / milestone ;) > > > I've been hesitant to jump into the testing and > stuff, as things are still > > in a state of changing. If I go spend a lot of > time identifying some > > problems and trying to fix, and then everything > changes with that widget, > > Just an idea: Shouldn't the core-api and the widgets > be 2 separate "subprojects"? > The DynAPI really rocks and is really needed even > w/o the widgets. So could there > be a DynAPI-Core-Freeze (some kind of freeze-state > makes the testing stuff really > easier and more meaningful)? Is there still so much > changing in the core-api? > If a DynAPI-core release comes earlier, then more > people will use it and > create own widgets. Not to forget the poor > developers who are only allowed > to use "official releases" by their bosses. > > What is the current separation? Is there something > like a core, widgets, the > soda-stuff etc? Or is it all just the DynAPI? If not > - do you like the idea > of splitting this up? > > > it's time not well spent. So we'd need to have > some sort of freeze state. > > But since there's been so much new activity with > people creating new things, > > I've been hesitant to call for a freeze. Maybe a > compromise is to have a > > list of things which are in a freeze state (while > allowing others to be > > developped a bit more), add no new features, just > do some testing, > > documentation, bug fixes, and set it aside until > release, putting any new > > ideas into a TODO list. Then when the freeze list > is empty, go back and > > freeze the remaining parts one by one or a few at > a time. How does this > > sound? > > This sounds like a great idea! > > Regards, > Peter > > > > ------------------------------------------------------- > This SF.net email sponsored by: Enterprise Linux > Forum Conference & Expo > The Event For Linux Datacenter Solutions & > Strategies in The Enterprise > Linux in the Boardroom; in the Front Office; & in > the Server Room > http://www.enterpriselinuxforum.com > _______________________________________________ > Dynapi-Dev mailing list > [EMAIL PROTECTED] > http://www.mail-archive.com/[EMAIL PROTECTED]/ __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ------------------------------------------------------- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[EMAIL PROTECTED]/
