Hi, "Sittampalam, Ganesh" <ganesh.sittampa...@credit-suisse.com> writes: > I think that we should either abandon them for the entire 2.5 series, or > slip 2.5. > > 2.5.x should just be bugfixes on 2.5, IMO. well, my line of reasoning is this:
These are fairly lightweight changes, both fixing a long-standing and annoying issue. On the other hand, 2.5 already has a lot to offer. So while I would like not to delay 2.5, I'd like to get these out sooner than in December. The process should be much more lightweight than a full release cycle. Whether we call it 2.6 or 2.5.1 is a minor point. I don't think there are going to be any more 2.5.x releases after 2.6 anyway, so even in this regard, it is equivalent. > If we feel we have a lot of worthwhile features that won't make 2.5 > and that we want to get out earlier than December, we could always > decide to have 2.6 early. That would require more release management > work by someone, but equally releasing 2.5 now and then letting them > into 2.5.1 also adds to the release management burden. True. But it shouldn't be more than maybe half dozen patches on top of 2.5, all fairly limited in scope. Since Eric pointed out we can disable the http-based downloads in 2.5 without introducing conflicts or breakage, I'd say it's fairly cheap, process-wise. At least when things that need to be fixed for 2.5 anyway are fixed already (broken --exact-version comes to mind). > There's precedent for unpulling on branches rather than rolling back. > Perhaps that would be a better route in view of the merging problems we > would get otherwise. Unpulling would work better if the patch already wasn't included in the beta and tagged accordingly. I guess. Yours, Petr. _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
