On Wed, Sep 15, 2010 at 2:27 PM, Brett Porter <[email protected]> wrote: > > On 15/09/2010, at 2:05 PM, Deng Ching wrote: > >> Hi All, >> >> Any objections in doing a milestone release of trunk before we merge >> MRM-980 branch? > > Depends on the intent... > > Clearly there are a lot of good improvements in trunk already, both in terms > of performance / bugs and a couple of new features like the arbitrary > metadata. > > However, if MRM-980 is done and just needs to be merged, I don't see any > reason to wait unless we don't feel it's up to the same level of quality as > the rest of trunk. Is that the case?
Yes, I think we can already merge it. As for the UI for MRM-980, there is still a lot of room for improvement but this can be worked on in trunk after the merge. > > As for trunk, while the refactoring work is production ready, the file store > is not. It's not far from being ready, and I know leaving trunk > "unreleasable" was less than ideal. I don't mind it being in a release, but > I'd only commit to make an upgrade path from 1.[1|2|3] -> 1.4, not through > the interim releases. In other words, if we release it as is, they need to be > prepared to rescan their repository regularly. I think such a release would > be an alpha, not a milestone, despite our previous naming conventions. I agree, the release should be an alpha release instead of a milestone. > > So, the question is who the audience / intent is - do we want people to kick > the tires on the refactoring, find bugs, and release an alpha now? Do we want > people to try out the new features and release an alpha/milestone with that? > Or do we really just want to push to what's needed for a release? The last one I would think. > > I think I'm fine with either an alpha release now (as long as another one > follows quickly), or one with the branch merged in now. Either way, we should > push forward to get 1.4 wrapped up in October. I vote for the latter -- merge first then do an alpha release after. Thanks, Deng
