Let's differentiate between feature-freeze and bug-fix freeze. IMO, we should cut a branch_45 "now", or as early as the RM intends to start working on the release. At that point, no new features should go into 4.5 anymore. If an issue hasn't been committed until then, I see no reason for it to get into the release eventually, no matter how good the committer/developer think it is. Fact is, it hasn't had any time baking in Jenkins, so how can we sign "OK" on it?
The problem seems to be what "now" means. For me, because of the nature of this project, 24h is the minimum, to let people in different time zones some time to even respond +/-1 on the idea of releasing. But if there's consensus to release and the RM intends to work on it right away, then the branch should be cut right away. After cutting the branch we can sort out outstanding "bugs" in JIRA and decide which should go into the release. Yes, I know it's more overhead for the committer, now merging into 4x and _45, but that's not too bad. I think that a week for RC0 is reasonable? it takes time to prepare the release anyway and if there are known bugs that people are working on, we should let them some time to fix them, but at most a week (unless they're blocker). In all our recent releases, we always had last minute issues (bugs found either before or after RC0). It's enough to handle them, and we don't need to risk more issues by allowing last-minute features too. Cutting the branch just means "feature freeze" and there's no point waiting with that. Not today at least, where we release way more often than before. Shai On Thu, Sep 12, 2013 at 2:55 AM, Yonik Seeley <[email protected]> wrote: > +1, a week at minimum seems very reasonable. > > -Yonik > http://lucidworks.com > > > On Wed, Sep 11, 2013 at 3:00 PM, Mark Miller <[email protected]> > wrote: > > I still believe, as I have voted before, that because we are a community > of developers spread across the world and work space, we should have some > warning for releases - we are collaborating here - people should have a bit > of time to tie up loose ends, investigate reports, weigh in about the > pending release, whatever, to help make a solid release. A week minimum has > always seemed reasonable to me. It's not enough time to slam in your latest > big feature - unless you are confident or marking it as experimental or > whatever consensus on that issue decides (we play by consensus) - but it is > enough time to harden, investigate, and tie up loose ends that have worried > you, but you have not tackled, not yet having the pressure of an impending > release. > > > > No one should *need* a release right now unless it's a critical bug fix > release. Otherwise it seems you can always bring it up a week before you > need it. And then everyone gets to play nice together even though this may > not be their first job or they may be in university for the weekend, or > whatever. > > > > So +1 to next Wednesday, -1 to right now. > > > > - Mark > > > > On Sep 11, 2013, at 12:35 PM, Adrien Grand <[email protected]> wrote: > > > >> Unless someone else volunteers to do the release, I'll be busy until > >> ~wednesday next week so there are still a few days to get fixes in > >> anyway. However I agree with Robert that our branch_4x should always > >> be stable and releasable. > >> > >> @Jack, @Erick could you share more details about the issues that need > >> to be fixed before a 4.5 release? > >> > >> -- > >> Adrien > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
