But there is a risk of releasing the orbit bundle just after creating. Those orbit bundles may get changed multiple times during the bug fixing phase. So we will end up releasing multiple minor versions. Just a thought.
Anyway I am +1 for releasing orbits immediately. On Fri, Jan 3, 2014 at 3:21 PM, Afkham Azeez <[email protected]> wrote: > > > > On Fri, Jan 3, 2014 at 3:16 PM, Samisa Abeysinghe <[email protected]> wrote: > >> Why do we need SNAPSHOT for orbits at all? It is just a wrapper of a >> released lib. So just create the new version and deploy into m2 - Done! >> >> > +1. This is what I suggested some time back too. > > >> Thanks, >> Samisa... >> >> >> Samisa Abeysinghe >> >> Vice President Developer Evangelism >> >> WSO2 Inc. >> http://wso2.com >> >> >> >> On Fri, Jan 3, 2014 at 2:43 PM, Kishanthan Thangarajah < >> [email protected]> wrote: >> >>> Our current approach of having third party dependencies as OSGi bundles >>> is to make them into an orbit project. The release of them happen with the >>> kernel or platform release. >>> >>> Because of this, currently when building carbon from source, we first >>> have to build orbit. But this is not needed if we maintain orbit as an >>> external project (may be in git-hub) and use one of the following. >>> >>> 1. Use SNAPSHOT repo approach. The developer who creates a new orbit >>> project will have to deploy the snapshot version of it to the repo. The >>> official release of those will happen on its own way. It can align either >>> with a kernel release or platform release (major or patch releases). >>> >>> 2. Releasing the newly created orbit project immediately after creating >>> it. This is possible because we don't normally do any changes to it (pom) >>> afterwards. This also has to be done by the developer (after all the >>> testing). The downside of this is we may end up with multiple versions for >>> a projects. But this will be minimal. >>> >>> In both cases above, the components requiring those orbit dependencies >>> will have to update to those released/snapshot versions. >>> >>> The orbit projects for forked dependencies will follow the same approach >>> as earlier. >>> >>> Suggestions and thoughts are welcome. >>> >>> Thanks, >>> Kishanthan. >>> >>> -- >>> *Kishanthan Thangarajah* >>> Senior Software Engineer, >>> Platform Technologies Team, >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - +94773426635 >>> Blog - *http://kishanthan.wordpress.com >>> <http://kishanthan.wordpress.com>* >>> Twitter - *http://twitter.com/kishanthan >>> <http://twitter.com/kishanthan>* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sameera Jayasoma, Architect, WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
