Return-Path: Delivered-To: apmail-incubator-aries-dev-archive@minotaur.apache.org Received: (qmail 91105 invoked from network); 27 Jan 2010 17:17:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 27 Jan 2010 17:17:25 -0000 Received: (qmail 90858 invoked by uid 500); 27 Jan 2010 17:17:24 -0000 Delivered-To: apmail-incubator-aries-dev-archive@incubator.apache.org Received: (qmail 90772 invoked by uid 500); 27 Jan 2010 17:17:24 -0000 Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: aries-dev@incubator.apache.org Delivered-To: mailing list aries-dev@incubator.apache.org Received: (qmail 90762 invoked by uid 99); 27 Jan 2010 17:17:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Jan 2010 17:17:24 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates 209.85.220.214 as permitted sender) Received: from [209.85.220.214] (HELO mail-fx0-f214.google.com) (209.85.220.214) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Jan 2010 17:17:15 +0000 Received: by fxm6 with SMTP id 6so749208fxm.27 for ; Wed, 27 Jan 2010 09:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=dEU7ssf38881xvZwA8GZJeVq4o5WJPf8Ts0koZMz1Lg=; b=EUpHuRcE6ZE/sW04EWHsH2BPY0tigAh16b7J+s/4qXvf58ifghfKkhX1wjwS6JxXwS u7Omw9nPd3KF7Js3GbcuOKTj57Giv6DuxJft2sP6n1lL9+8GCkUg/PoZUdhEYym4pPWm Rwthwg3KEqtFLPi4GSH/8NANWMJFiIG0EWVy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IsFBbBzHa+MXRxYR9CeiNrt/eaHEbTXbJrWJjmTx70ts7c4y0SfjK9O+ZVs0DU0qVn CpIt4XXvC6ROAncb6/2FvbcVJckrlPOkv7V49r60Veh0E7HuwrEtCnk9yszWxRwnw5n7 F5uqIgAItI7BKugvqssVPPebXxhMgJrjpx82s= MIME-Version: 1.0 Received: by 10.223.14.89 with SMTP id f25mr2161422faa.15.1264612614268; Wed, 27 Jan 2010 09:16:54 -0800 (PST) In-Reply-To: References: <6D4B9837-53A0-4A0C-B51E-7B67E156F9F4@toolazydogs.com> Date: Wed, 27 Jan 2010 18:16:54 +0100 Message-ID: Subject: Re: [DISCUSSION] Aries release From: Guillaume Nodet To: aries-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it would seem more natural to have a single version across the components if we will always release those together. Having different versions only makes sense if these components are released independently. I've seen both happen in different projects. It seems that having a single version / release makes our life and our users' life easier (only one version to remember / upgrade, a single release to do). It would also enable us to provide a binary distribution, but it somewhat makes the release cycle longer as all components need to be ready. I don't really have a strong opinion on that, but i'd rather start with a single release and later switch to multiple versions if needed. On Wed, Jan 27, 2010 at 17:58, Alasdair Nottingham wrote: > I think the only component in aries I think could be marked as 1.0 in > the first release is the blueprint component. However I would like to > see a discussion about how versioning works, whether we keep it in > lock step or independently versioned, and linked to this whether the > sub-components can be released independently of each other before we > ship blueprint at 1.0 and everything else at 0.1 > > I don't know how long this discussion would take, but I wouldn't want > to hold up a first release for a long time to have the discussion > since it only affects a single component at this time. > > Thoughts? > Alasdair > > 2010/1/27 Alan D. Cabrera : >> >> On Jan 27, 2010, at 3:45 AM, Alasdair Nottingham wrote: >> >>> I would not like to do a 1.0 release of components that implement an >>> OSGi spec, but have not passed compliance. Since a lot of the >>> specifications are not yet final we should not be releasing 1.0 >>> implementations of those specification. >> >> Makes sense to me. >> >>> This doesn't apply to blueprint since the spec is final, but for the >>> other components I think we should stick with 0.1 for now. I do not >>> have a strong opinion on using separate versioning for the components >>> right now, but I do think it might make sense for our first release to >>> be consistent across components. >> >> So for blueprint it should be 1.0 and the others 0.1? >> >> >> Regards, >> Alan >> >>> >>> Alasdair >>> >>> 2010/1/27 Alan D. Cabrera : >>>> >>>> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote: >>>> >>>>> There's been a lot of activity lately so I'd like to propose we do a >>>>> release so we can get some wider user feedback. I think we should giv= e >>>>> it a version of 0.1 and stick to versions <1 while we're in the >>>>> Incubator. >>>> >>>> I'm in favor of a release but prefer to call it 1.0. =A0Why does it ma= tter >>>> that we're in the incubator? =A0Just curious. >>>> >>>>> Then there is the question of whether to independently version the >>>>> high level modules or keep them lock-step. For now I think we should >>>>> keep them lock-step until we feel a need to change that. >>>> >>>> I think that there's a strong chance that we will have patch releases >>>> that >>>> would affect only one module. =A0I think it would be odd and confusing= if >>>> the >>>> versions for the other modules were incremented as well, especially si= nce >>>> not all the modules will always be consumed together. >>>> >>>> >>>> Regards, >>>> Alan >>>> >>>> >>> >>> >>> >>> -- >>> Alasdair Nottingham >>> not@apache.org >> >> > > > > -- > Alasdair Nottingham > not@apache.org > --=20 Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com