Am Montag, den 29.05.2006, 14:55 -0400 schrieb Noel J. Bergman: > people can see the changes as they happen. The fetchmail > code might have been a good example of when to use a branch, since it > was > relatively isolated, and would have been easy to merge in afterwards. > Steve > wasn't saying that the changes were bad, he was saying that the > changes were > substantial, and without having good testing coverage, they are very > risky > to replace code in trunk that is generally considered to be working.
Its everytime a risk.. So lets move on and write junit test so we can be sure that it work like aspected. Maybe you notice that i start with matcher junit tests.. I try to write in the first step junit tests for all matcher/mailets and SMTPCmdHandlers. > > > James is a great project but sometimes we take to long > > Yes. And one of the things that held us up for a long time was making > changes that blocked our ability to get good releases out the door. > I'd > like to learn from that, and avoid a repeat. Ok so let us make a roadmap! What changes should be made in 2.x releases ? what to make in 3.x ? We need to know for making the changes on the right release (time). Should we use a trunk ( for all work) , 2.3-branch (for merging to current release),2.4-branch (for merging for next release) ,3.0-branch (for next milestone changes) ? What the other guys think ? bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
