Thanks for the detailed mail Sameera.

However, I think the platform version number we're using is wrong. I
thought we agreed that the first release was release 1 and so the Turing
release is 28 or 29 or whatever the current release iteration is.

That is,

platform = carbon kernel + set of compatible products

So using the Carbon kernel version as the platform version is wrong! The
table has Turing marked as version 4.2.0 of the platform and the kernel
version is 4.2.0. Those are independent and using the same number will
bring back the confusion we've had for years.

If my logic is correct, then shouldn't the P2 repo URL be
http://dist.wso2.org/p2/carbon/releases/turing (or maybe 29-turing)?

Also, the release matrix should link directly to the P2 repo and not to
http://wso2.com/projects/carbon/provisioning-wso2-carbon-with-equinox-p2.
(BTW that page is random and weird .. looks like some leftover from the
.org/.com merger as the URL is random - will sort it out.)

In the table (which looks nice!) shall we separate product name and product
version into two columns? I can imagine multiple versions of the same
product being released for the same platform in different release chunks. I
wish we could come up with a better word than "chunk" since that's exposed
to the world now.

Sanjiva.


On Sat, Sep 21, 2013 at 4:14 PM, Sameera Jayasoma <same...@wso2.com> wrote:

> Hi Folks,
>
> Let me start with a little bit from the WSO2 Carbon release history. From
> 2009 to early 2012,  Carbon kernel, Carbon platform and the set of products
> shared the same source repository and they all shared the same version
> except for products. So in all the previous releases, we had to release
> everything even though we needed a new kernel release or a new platform
> release. Also the source repository became somewhat unmanageable at that
> time. We wanted to independently release Carbon kernel and Carbon platform.
> I.e. Carbon platform trunk should be able to depend on a released Carbon
> kernel version.  Therefore we split the source repository into three
> different repositories called Carbon orbit, Carbon kernel and Carbon
> platform. This decision allowed us to work on these projects indipendenly.
>
> But we did a mistake again by using the same version for the Carbon kernel
> and the platform. Another mistake is to maintain a P2 repository for
> a Carbon kernel version assuming that all the products/features which are
> released on a given kernel version are compatible with each other. In the
> past year or so our assumption has been proven wrong. We have been
> introducing incompatible changes in patch releases of certain products and
> P2 story is broken in the past two major Carbon releases.
>
> Recently we had a meeting to rectify this issue. Participants are Sanjiva,
> Azeez, Sumedha and bunch of few others. I have explained the solution below
> in point form.
>
>    - We need to highlight the Carbon platform release concept more. We
>    need to introduce two different versions/names for the platform releases
>    and the kernel releases. There can be multiple platform releases based on
>    a single kernel release.
>
>
>    - A Carbon platform release consists of a bunch of product releases
>    which are compatible with each other. I.e features of a AS should work
>    seamlessly with another product say ESB  given that both these products
>    belongs to a single platform release. Recent requirements clearly shows the
>    need of a set of compatible products to build something like WSO2 Cloud.
>
>
>    - We need to maintain a P2 repository for a Carbon platform release
>    not for a kernel release. Product which belongs to single platform version
>    should be able connect to this repo and install features and run without
>    any issues. I.e all the product feature. When ever we do a patch release of
>    a product, we should not do any incompatible changes to the same platform.
>    If you need a this sort of a change, you can initiate new platform release.
>
>
>    - Practically we cannot release all the products at once. Therefore we
>    need to follow a chunk based release model[1] when it comes to releasing
>    products and patch releases of products.
>
>
>    - We thought of naming Carbon platform releases after the Turing award
>    winners. We named first platform release(4.2.0) as Turing.
>
>
>    - I have worked with Dassa(Dasun) to update the release matrix page[2]
>    to illustrate these facts.
>
>
> Please share your thoughts on this.
>
> Thanks,
> Sameera.
>
> [1]
> https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.2.0/product-releases/
> [2] http://wso2.com/products/carbon/release-matrix/
>
> --
> Sameera Jayasoma,
> Architect,
>
> WSO2, Inc. (http://wso2.com)
> email: same...@wso2.com
> blog: http://sameera.adahas.org
> twitter: https://twitter.com/sameerajayasoma
> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
> Mobile: 0094776364456
>
> Lean . Enterprise . Middleware
>



-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
650 265 8311
blog: http://sanjiva.weerawarana.org/

Lean . Enterprise . Middleware
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to