Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5BB5B10E67 for ; Tue, 2 Dec 2014 19:33:26 +0000 (UTC) Received: (qmail 10310 invoked by uid 500); 2 Dec 2014 19:33:26 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 10275 invoked by uid 500); 2 Dec 2014 19:33:26 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 10263 invoked by uid 99); 2 Dec 2014 19:33:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2014 19:33:25 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rob.j.godfrey@gmail.com designates 209.85.216.44 as permitted sender) Received: from [209.85.216.44] (HELO mail-qa0-f44.google.com) (209.85.216.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2014 19:33:20 +0000 Received: by mail-qa0-f44.google.com with SMTP id i13so9207187qae.17 for ; Tue, 02 Dec 2014 11:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=d7tlpPoJlrvErFiKcB3bmtsyLdR4/KLXzxRuqEY5iOI=; b=gKTV2cxNiVO8Rs14paWs7xUif3xLx7YaOXkiALydCNlvQUEv9jtj6JRo7ohla79erV Am14Z2m4FoBMjrpWD1W4/WD3ADW1fYNzfiTTt0gFlCXCWUcWvG8RNrl2gqIyHANCRoDz RZn5nMEntUDxOGd9UZrdxiyszhVIXl3rkpGC6/V6uK+DWIO/wqMtu7dltED3R1jERNw4 20rFkjE1Nuy0U4fM7TxAF7vQSTBH6KyttWm0uT6xrpJG/YqURybfpu5sAeA6xIdgdgGI +Rzo9jXaFJXD3kKgB8LlO6AsmZ/Z2yz6Q1pvzu4k08btk6pQcc9p2jZZVFKPIbzfxBSG 92+Q== MIME-Version: 1.0 X-Received: by 10.229.176.198 with SMTP id bf6mr1411312qcb.12.1417548690225; Tue, 02 Dec 2014 11:31:30 -0800 (PST) Received: by 10.140.102.227 with HTTP; Tue, 2 Dec 2014 11:31:30 -0800 (PST) In-Reply-To: References: <547CE797.9060108@gmail.com>

Date: Tue, 2 Dec 2014 20:31:30 +0100 Message-ID: Subject: Re: Any ETA on a QPid 0.32 release From: Rob Godfrey To: "users@qpid.apache.org" Content-Type: multipart/alternative; boundary=001a11c3057e220145050940c660 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c3057e220145050940c660 Content-Type: text/plain; charset=UTF-8 On 2 December 2014 at 19:25, Robbie Gemmell wrote: > On 2 December 2014 at 16:14, Rob Godfrey wrote: > > Can we also move from version 0.32 to something more reflective of the > > maturity of the product? > > > > Seems reasonable. > > > I feel like we've held off so long that going to release "1.0" now would > > seem strange, and also imply something significant had happened in that > > release which it hasn't. > > Agreed. > > > Personally I'd go for something like 15.1 (not > > necessarily to indicate that we'd go for year.month in the future... but > > just as a arbitrary starting point). > > .0 or .0 would suit me too. > > I'd quite like at least some components to support point releases > eventually instead of just timed released, so in some ways arbitrary > numbers seem preferable such that we dont end up doing too many odd > looking point releases or even skipping numbers for slow moving > components hehe. > > Agreed - this is something I want to support too... from where I sit that will be easier when each component has more control over their release timelines. > > I'd also be in favour of separating > > out the components a bit - from the Java side we'd probably then look to > > branch later but spend less time on a branch before release. > > > > Do you mean branch at different points but still potentially release > at similar times, or release at independent times? The latter was what > I meant. > The latter should be possible, the former might be socially convenient (and also mean less overall need for interop testing between components, which is not something we seem to have well automated). One of my problems with the current release process is that we always tend to take a *long* time in the branched state, and the branching seems to occur at a somewhat arbitrary point. I'd rather be saying "OK, we as a collection group of developers for now believe we are ready to go to beta"... > > A question for me is, if we did support releasing at different times > then things will likely end up with different version numbers anyway, > so do they need to start at the same place if we change from our > historic naming convention? Would it be clearer or more confusing if > they differed initially, or started the same and then diverged? > Right now it seems to me that the only coupling between the Java and C++ releases is temporal, not functional. If we use a non date based version numbering system, the coupling of the Java and C++ releases seems somewhat odd - we don't currently (nor have we really ever) planned across the whole project to coordinate functional releases. Similarly there's never really any "good" time to move up major version while the releases are coupled (since we never do "major" stuff at the same time) which is why I think we've never gone to v1.0 previously. > > One thing that I have mentioned before is that if we were to look at > branching at different times, I think the repo needs better organised > along the structure of likely branching, otherwise it just becomes a > pain and the branches end up with potentially confusing junk on them > for other bits. . > Agreed on better structure - I think git is somewhat orthogonal... We need to get the structure right whatever. -- Rob > Robbie > > > > -- Rob > > > > On 2 December 2014 at 16:48, Robbie Gemmell > > wrote: > > > >> The releases have usually been every 4 months or so, and the branch > >> for the last release was made about 4 months ago, so I guess the plan > >> should be to branch sometime soon. Typically releases that begin in > >> Nov/Dec dont emerge until some point in January. Any plans on dates > >> Justin? > >> > >> Of course, we have discussed the project being more modular, updated > >> the release artifacts along those lines to be more component based, > >> and voted on them seperately last time round, so potentially we could > >> look to take a further step and release different bits at different > >> times now. Thoughts anyone? > >> > >> Robbie > >> > >> On 1 December 2014 at 22:11, Timothy Bish wrote: > >> > We've been working on improving the AMQP 1.0 support in ActiveMQ and > I've > >> > found that the trunk code for QPid JMS client contains some fixes that > >> would > >> > be nice to have in for testing the fixes that are in the pipeline for > the > >> > broker. Was wondering if there is any idea on when the 0.32 release > >> process > >> > might start rolling? > >> > > >> > -- > >> > Tim Bish > >> > Sr Software Engineer | RedHat Inc. > >> > tim.bish@redhat.com | www.redhat.com > >> > skype: tabish121 | twitter: @tabish121 > >> > blog: http://timbish.blogspot.com/ > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org > >> > For additional commands, e-mail: users-help@qpid.apache.org > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org > >> For additional commands, e-mail: users-help@qpid.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org > For additional commands, e-mail: users-help@qpid.apache.org > > --001a11c3057e220145050940c660--