On Thu, May 5, 2011 at 6:02 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> We've still got bugs (we'll always have bugs), but I think getting > more testing via the pre-releases is important at this stage, and I > see branching as a step toward cutting pre-releases. I am not a huge fan of alpha/beta releases. I just do not think they provide a lot of value as you rarely get back any feedback. We did this with 1.5 and even put a fair amount of effort into publicizing it and providing binaries etc. Yet I recall we did not start getting any real feedback and evidence that people were looking at the releases until we got to the final release candidates and it was getting obvious we were about to release. I realize there are some projects that have had success with this sort of thing, I just do not think we are one of them. My main concern is that it would actually slow down the release process as we get to a point where we are somewhat waiting for feedback that never arrives. > I do not think we need to have trunk in a releasable state before > branching, but I would like to find a way to start doing pre-releases > relatively soon-ish. I suppose we could cut alpha releases directly > from trunk, but that would be a break with precedent, and doesn't > really feel good. What is your concern with this? I do not see why it would be a problem. I am not sure what your definition of "releaseable state" is, especially in regards to an alpha/beta release, but I think trunk is in this state. I have been publishing Windows binaries of trunk builds and I believe that TortoiseSVN does as well. > If the branch is not in a releasable state, I'd propose we cut alpha > or beta releases, and release them along with a list of known issues, > similar to what we did for 1.5. This would allow more testing. > Voting rules on the branch could be relaxed up until the first release > candidate, also similar to 1.5, in an effort to get changes on to the > release branch with as little friction as possible. If we really wanted to do something, I would suggest something like this. 1) Define a reasonable target date when we think we are going to branch and be ready for RC1. Let me just make up a date and say June 8th, 2) Issue a beta1, beta2, beta3 like clockwork every week leading up to the date. These would just be cut from trunk and go through no or minimal voting. I would probably just be sure to use a revision where buildbot is green. 3) Publicize these plans and the betas leading up to it. Each beta should list the known issues that are currently blocking the release. Encourage users to report issues they see as release blockers. 4) We should obviously try to meet the date we set for ourselves as other open-source projects do, but obviously the software has to be ready to actually get to that final branch/rc1 state. All known release blockers must be closed and the release would go through normal release process. > This feels like something that could happen before the end of the > month, but I'm sure others have insight into what is blocking the > branch, so please speak up. I have been encouraging people to use the 1.7.0 milestone for anything that is a blocker. Paul added issues for every XFail and annotated the tests. Other things that normally slow us down like release notes and CHANGES seem good. I think we should rely on the issue tracker to enumerate the blockers. If people cannot be bothered to create an issue for something than it is not a blocker. BTW, I agree things are looking good. -- Thanks Mark Phippard http://markphip.blogspot.com/
