On Thu, Jul 24, 2014 at 2:55 PM, Gregory Chanan <[email protected]> wrote:
> Thanks for the reply, Sravya. Comments inline. > > > On Thu, Jul 24, 2014 at 2:45 PM, Sravya Tirukkovalur <[email protected]> > wrote: > > > Hi Greg, > > > > Comments in line. > > > > On Thu, Jul 24, 2014 at 1:58 PM, Tuong Tr. <[email protected]> > > wrote: > > > > > Hi Greg, > > > > > > The process of bumping release number will be done as part of the > release > > > subtasks. The official Apache release process calls for 2 weeks > notice. > > > It may not be needed for Sentry, but I am also out of the office next > > week > > > :)) So we decided to stick to the recommended wait-out. > > > > > > For your patch, Sravya's recent commit (5862bbe) has updated the > version > > > to 1.4.0-incubating-SNAPSHOT. If you update your dependency to that, > it > > > will keep you stable and up-to-date until 1.4.0 is released. > > > > > > Respectfully, > > > Tuong > > > > > > > > > On Thursday, July 24, 2014 1:12 PM, Gregory Chanan < > [email protected] > > > > > > wrote: > > > > > > > > > > > > Hi Tuong, > > > > > > Thanks for taking this on, we definitely appreciate all the effort! > > > > > > One thing I haven't seen discussed is what to do about dependency > > versions > > > -- are we planning to bump to released versions for 1.4.0, like we did > in > > > 1.3.0 (https://issues.apache.org/jira/browse/SENTRY-171)? > > > > > I think it is a good idea to update to non snapshot versions before the > > release. Will file a jira. > > > > > > > One reason I'm asking is because of SENTRY-354 ( > > > https://issues.apache.org/jira/browse/SENTRY-354) -- I need to bump a > > > version number for that patch, but don't think it's appropriate until > > after > > > 1.4.0 is brached. To avoid these sorts of issues where trunk progress > is > > > stalled while we "help keep trunk stable", I generally prefer to branch > > > sooner rather than later. Could you describe why you want to wait 2 > > > weeks? > > > > > > > Yeah, there is definitely an advantage of branching sooner to continue > > active development on the trunk. But also giving some padding time before > > branching would give community some time to push in some commits that > they > > are really interested in especially the ones which can get more stability > > to the project. May be that is the reason Apache usually recommends 2 > weeks > > of padding time before cutting the release. > > > Sure, I'm only talking about branching the code repository, not about > stopping development or initiating the release process (i.e. cutting RCs). > Presumably, we'd just have two branches in git: > 1) master with version 1.5.0-incubating-SNAPSHOT > 2) branch-1.4.0 with version 1.4.0-incubating-SNAPSHOT > commits that add stability to the project can be committed to both master > and branch-1.4.0. New (unstable) development should only be committed to > trunk. I think all that would need to be done > is to push a new branch to git from current master to branch-1.4.0 and then > update the versions of both. > > I think the only other thing we'd want to do is to create a build for > branch-1.4.0 so we keep updating the maven repo. I assume the current > builds just built trunk. I don't know if that's difficult. > > Yes, this is one option. And the other option is lets go ahead committing everything to the trunk, but mark the fix version as 1.5.0 for the risky ones (but restrain from it if possible) and as 1.4.0 for the stable ones. And we can selectively pick the commits while branching. As long as there are no conflicting commits, we should be good. This way, we do not have to setup a new job just for a week? This option seems better especially given that Tuong would be OOO next week and will not be able to monitor the release branch. > > > But if you want to commit some > > patches but do not want to put in 1.4.0 release, we should be able to cut > > the branch from a previous commit and selectively cherry pick other > commits > > right? > > > > > Right, I think this is what I'm describing above. > > > > > > > Thanks, > > > Greg > > > > > > > > > > > > > > > On Tue, Jul 22, 2014 at 6:21 PM, Tuong Tr. <[email protected]> > > > wrote: > > > > > > > Hi Sentry Community, > > > > > > > > As you may know, we are getting ready to release Sentry 1.4.0. > > > > Our plan is to branch on Tuesday, August 5th. > > > > > > > > There are currently about 24 unresolved JIRAs that have > > > > fix-version as 1.4.0. By EOD today, I will move all those to the > > next > > > > release. > > > > If you would like to commit > > > > any of these JIRAs into 1.4.0 release, you will need to change the > > > > fix-version back to > > > > 1.4.0. > > > > > > > > Please help keep trunk > > > > stable in the next 2 weeks so we can have a smooth release. > > > > > > > > SENTRY-365 (https://issues.apache.org/jira/browse/SENTRY-356) has > been > > > > created to track the release activity. > > > > > > > > > > > > Let me know if you any question or > > > > suggestion. > > > > > > > > Respectfully, > > > > Tuong > > > > > > > > > > > -- > > Sravya Tirukkovalur > > > -- Sravya Tirukkovalur
