You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sentry.apache.org by "Tuong Tr." <ir...@yahoo.com.INVALID> on 2014/07/23 03:21:54 UTC
Release work for Sentry 1.4.0 has started
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
Re: Release work for Sentry 1.4.0 has started
Posted by Gregory Chanan <gc...@cloudera.com>.
Hi Tuong,
I'm not familiar with the 2 weeks notice for releases you mentioned. But
in any case, I'm only talking about branching the code, not doing a
release, and I don't know of any rules against branching. I'm totally
content with waiting 2 weeks to initiate the actual release process.
On the patch you mentioned, we aren't talking about the same thing and I
apologize that my message above wasn't clearer. You are talking about what
to do to a project that is dependent on Sentry. I need to update Sentry's
dependency on another project (solr-sentry-handlers) and I want to do that
for sentry version 1.5-SNAPSHOT, not 1.4. If we don't branch, all the
patches that shouldn't go into 1.4, like this one, are basically left in
limbo for two weeks.
Greg
On Thu, Jul 24, 2014 at 1:58 PM, Tuong Tr. <ir...@yahoo.com.invalid> 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 <gc...@cloudera.com>
> 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)?
> 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?
>
> Thanks,
> Greg
>
>
>
>
> On Tue, Jul 22, 2014 at 6:21 PM, Tuong Tr. <ir...@yahoo.com.invalid>
> 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
>
Re: Release work for Sentry 1.4.0 has started
Posted by Sravya Tirukkovalur <sr...@cloudera.com>.
On Thu, Jul 24, 2014 at 3:23 PM, Gregory Chanan <gc...@cloudera.com>
wrote:
> I'm not totally against the idea, but if the concern is the time it takes
> to set up the 1.4 job, why don't we just not do it? Our published
> 1.4.0-SNAPSHOT will be out of date for a bit if commits go in there, but:
> 1) we don't guarantee anything on those SNAPSHOT branches anyway
> 2) if people want more up to date versions, they can use 1.5.0-SNAPSHOT or
> wait for the proper 1.4.0 release.
>
> Thoughts?
>
Thats a good point! Yes, I think that should be fine too.
> Greg
>
>
> On Thu, Jul 24, 2014 at 3:13 PM, Sravya Tirukkovalur <sr...@cloudera.com>
> wrote:
>
> > On Thu, Jul 24, 2014 at 2:55 PM, Gregory Chanan <gc...@cloudera.com>
> > wrote:
> >
> > > Thanks for the reply, Sravya. Comments inline.
> > >
> > >
> > > On Thu, Jul 24, 2014 at 2:45 PM, Sravya Tirukkovalur <
> > sravya@cloudera.com>
> > > wrote:
> > >
> > > > Hi Greg,
> > > >
> > > > Comments in line.
> > > >
> > > > On Thu, Jul 24, 2014 at 1:58 PM, Tuong Tr. <iramus@yahoo.com.invalid
> >
> > > > 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 <
> > > gchanan@cloudera.com
> > > > >
> > > > > 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.
> <iramus@yahoo.com.invalid
> > >
> > > > > 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
> >
>
--
Sravya Tirukkovalur
Re: Release work for Sentry 1.4.0 has started
Posted by Gregory Chanan <gc...@cloudera.com>.
I'm not totally against the idea, but if the concern is the time it takes
to set up the 1.4 job, why don't we just not do it? Our published
1.4.0-SNAPSHOT will be out of date for a bit if commits go in there, but:
1) we don't guarantee anything on those SNAPSHOT branches anyway
2) if people want more up to date versions, they can use 1.5.0-SNAPSHOT or
wait for the proper 1.4.0 release.
Thoughts?
Greg
On Thu, Jul 24, 2014 at 3:13 PM, Sravya Tirukkovalur <sr...@cloudera.com>
wrote:
> On Thu, Jul 24, 2014 at 2:55 PM, Gregory Chanan <gc...@cloudera.com>
> wrote:
>
> > Thanks for the reply, Sravya. Comments inline.
> >
> >
> > On Thu, Jul 24, 2014 at 2:45 PM, Sravya Tirukkovalur <
> sravya@cloudera.com>
> > wrote:
> >
> > > Hi Greg,
> > >
> > > Comments in line.
> > >
> > > On Thu, Jul 24, 2014 at 1:58 PM, Tuong Tr. <ir...@yahoo.com.invalid>
> > > 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 <
> > gchanan@cloudera.com
> > > >
> > > > 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. <iramus@yahoo.com.invalid
> >
> > > > 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
>
Re: Release work for Sentry 1.4.0 has started
Posted by Sravya Tirukkovalur <sr...@cloudera.com>.
On Thu, Jul 24, 2014 at 2:55 PM, Gregory Chanan <gc...@cloudera.com>
wrote:
> Thanks for the reply, Sravya. Comments inline.
>
>
> On Thu, Jul 24, 2014 at 2:45 PM, Sravya Tirukkovalur <sr...@cloudera.com>
> wrote:
>
> > Hi Greg,
> >
> > Comments in line.
> >
> > On Thu, Jul 24, 2014 at 1:58 PM, Tuong Tr. <ir...@yahoo.com.invalid>
> > 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 <
> gchanan@cloudera.com
> > >
> > > 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. <ir...@yahoo.com.invalid>
> > > 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
Re: Release work for Sentry 1.4.0 has started
Posted by Gregory Chanan <gc...@cloudera.com>.
Thanks for the reply, Sravya. Comments inline.
On Thu, Jul 24, 2014 at 2:45 PM, Sravya Tirukkovalur <sr...@cloudera.com>
wrote:
> Hi Greg,
>
> Comments in line.
>
> On Thu, Jul 24, 2014 at 1:58 PM, Tuong Tr. <ir...@yahoo.com.invalid>
> 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 <gchanan@cloudera.com
> >
> > 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. <ir...@yahoo.com.invalid>
> > 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
>
Re: Release work for Sentry 1.4.0 has started
Posted by Sravya Tirukkovalur <sr...@cloudera.com>.
Hi Greg,
Comments in line.
On Thu, Jul 24, 2014 at 1:58 PM, Tuong Tr. <ir...@yahoo.com.invalid> 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 <gc...@cloudera.com>
> 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. 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?
> Thanks,
> Greg
>
>
>
>
> On Tue, Jul 22, 2014 at 6:21 PM, Tuong Tr. <ir...@yahoo.com.invalid>
> 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
Re: Release work for Sentry 1.4.0 has started
Posted by "Tuong Tr." <ir...@yahoo.com.INVALID>.
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 <gc...@cloudera.com> 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)?
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?
Thanks,
Greg
On Tue, Jul 22, 2014 at 6:21 PM, Tuong Tr. <ir...@yahoo.com.invalid> 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
Re: Release work for Sentry 1.4.0 has started
Posted by Gregory Chanan <gc...@cloudera.com>.
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)?
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?
Thanks,
Greg
On Tue, Jul 22, 2014 at 6:21 PM, Tuong Tr. <ir...@yahoo.com.invalid> 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