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 <[email protected]> wrote: > 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 >
