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 commited 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. > 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 >
