> When the implementation for one of the changes is > ready, we are going > to review and then commit it. If the changes are > big, it might be > useful to create a branch so that people can easily > compare old and > new versions of it.
An obvious (re)statement here, but the top dogs need to put the release of 1.3 as top priority, whereby (I assume) the "must always support" feature set will be defined. If I have understood the discussions correctly, the 1.3 release will be the *last* release to ever consider breaking existing build files. If 1.3 is considered the "official" feature definition, then the tasks that I proposed can be worked on in a branch and tested against the behavior of the official 1.3 release. Sort of like how Sun implemented javac and (sort of) worked out the bugs and features, and then reworked it again to make it faster. I also recommend a branch approach so that those of us interested in the refactoring work can deal with the buglets, which those working on tasks, etc. don't have to deal with those issues. Simeon PS: I know that CVS branches can be a pain, but I have successfully used them in the past. One just has to be careful and RTFM before doing it. __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/
