On Thu, Feb 14, 2013 at 12:21 PM, Stefan Sperling <s...@elego.de> wrote: > Philip indicated yesterday on IRC that all local move features > he wanted to get to implemented for 1.8 now have code written. > So now we're all waiting for the "local moves" yellow light on > roadmap.html to turn green.
That is good to hear. I saw Ben committed some tests as well. I did see him declare victory anywhere though, so I am assuming he still plans to add more? > I think we're at the point where we need testing by real users. > We've got some test coverage in our test suite that indicates things > are all well. But the test suite is somewhat removed from the actual use > cases which local moves are supposed to improve. For instance, we > haven't yet seen a single off the mill Java developer hit the 'refactor' > button in an IDE and then update the working copy. > > I expect that there are bugs lurking in the implementation of local > moves, and I also expect that we can still improve the user interface > a bit. But to get there we need some feedback from the outside world > about what does and what doesn't work. > > I think now is the time where we should either start cutting 1.8 alpha > releases from trunk, or branch 1.8 and then start issuing alpha releases > from the branch. In either case we should ask the community to build > binaries and ask our user base to help test them. (I don't expect alpha > builds to be used in IDEs, however many users could try to update > refactored working copies with the command line client and report back. > This would also be a good test for the 'svn upgrade' code.) > > What do you all think? I am not a huge fan of alphas in general just because I do not think many people really try them and in a disconnected communications environment like we are in, it can lead to a lot of time wasted waiting on feedback that never comes. That is not to say that I do not think we should cut one or two. If we get some early feedback that would be great. Mainly, I would just be concerned that we take our foot off the gas while we wait for people to tell us it works or does not work. I think one possible advantage to staying on trunk a bit longer, besides the simpler process, is that maybe it will keep people from holding off on work for post-1.8 a little longer. I would be a little concerned if we branched right now that some work on new 1.9 features might start landing on trunk before we even get 1.8 released and this might just complicate the backport process. Obviously it would be even worse if some of that stuff happened BEFORE we branch, but I think branching is kind of a signal that trunk is open for next release stuff. Anyway, it is great to see the progress. I am not against either option, just throwing some more ideas out there for consideration. -- Thanks Mark Phippard http://markphip.blogspot.com/
