Given that Canary builds are intended as a development aide, publication of
a binary for one platform should not be hinged on whether the Canary
successfully builds for all platforms.

In addition, I would prefer we don't start tying the publication of the
Tizen Crosswalk binary to the build of an optional extension module, unless
t-e-c is rolled in as part of a single crosswalk RPM for Tizen.

James


On Thu, Oct 3, 2013 at 9:43 AM, Raphael Kubo da Costa <
[email protected]> wrote:

> Caio Marcelo de Oliveira Filho <[email protected]> writes:
>
> > Hi Raphael,
> >
> > I don't think we need to tie it with Crosswalk version (and possibly
> > never). The C API t-e-c is built on (Crosswalk Extension C API) is
> > pretty stable, so they are mostly independent.
> >
> > I rather keep t-e-c in "rolling release" mode for a while longer (so
> > incrementing minor and keeping 0 as major) is fine by me. At some
> > point (maybe the same time we do Crosswalk 3 branch) we can branch de
> > t-e-c to 1 and make it folow the same approach as Crosswalk (wrt to
> > branches and such).
> >
> > What do you think?
>
> Fine for me.
>
> On the release builds side, it would mean t-e-c is going to be built
> every day after crosswalk-tizen itself is built on the canary VM, and a
> build will only succeed (ie. the binaries will be copied to 01.org and
> the version numbers will be incremented) if and only if android-x86,
> tizen and t-e-c all build correctly.
>
> And every day the minor version will be monotonically increased if the
> build succeeds.
> _______________________________________________
> Crosswalk-dev mailing list
> [email protected]
> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
>
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Reply via email to