Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [thym-dev] Discovery of Downloadable Cordova engines.



On Mon, Jul 21, 2014 at 10:39 AM, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:
On 21 Jul 2014, at 14:04, Gorkem Ercan wrote:

I wanted a larger discussion than bugzilla for this one but you are right
bugzilla should receive this definition.

The problem with auto detecting the minor version is on the long term if
Cordova project start to do independent releases it will be possible to
have a scenario as

Cordova 4.0
 iOS 3.9.1
 Android 4.1
I can not think of auto detection mechanism for this scenario

But that is what I suggest - you use the definition you refer to as the way to define
the default version but then allow user to explicitly override it in config.xml.

I think allowing users to configure the cordova library versions at the platform level is a step further this. Right now, I need a long lived mechanism for determining what to download when someone requests Cordova X.Y. As an example cordova CLI uses [1] to determine what to download. 



This could of course be marked as a warning that its not a recognized/validated runtime
and your usecase above where ios is 3.x based and cordova 4.0 I assume is considered
api incompatible...(assuming cordova version numbers has any meaning)


If independent releases adopted at would mean that Cordova has made a breaking change most likely on tooling but for those using the iOS without the tools there is no effect. Again independent platform releases are not a sure thing to be adopted and its main motivation is to be able to make platform releases quicker. 
 
/max


--
Gorkem



On Mon, Jul 21, 2014 at 5:36 AM, Max Rydahl Andersen <manderse@xxxxxxxxxx>
wrote:

On 19 Jul 2014, at 21:02, Gorkem Ercan wrote:

Due to bug 439650 [1], we need to change the way we discover downlodable
Cordova engines. At the moment we make the assumption that all Cordova
Engines for all platforms share the same version for a particular Cordova
version. Although this is usually the case, it is not always true (as seen
on the bug report). Furthermore, Cordova project is discussing to make
platforms make releases more independently.  Also there is an ongoing
experiment to provide Cordova downloads through npm which may eventually
cause us to adjust download locations for some versions.

So my proposal is to introduce a new extension point that provides the
downloadable Cordova Engine information. Basically,a collection of cordova
versions, with included platform library versions and download URLs.  The
default implementation of the extension point will be provided by Thym and
will provide the information for distros from Cordova project. And in
order
to be able to catch up with Cordova releases (without the need for Thym
releases) the plan is to make the implementation retrieve the info from a
json file hosted in our repo.

I am also planning to make the extension point overwritable by products.
So
if an adopter of Thym wants to use its own engines, it would be possible.

I should be able to push an early implementation soon, in the meanwhile
any
concerns, questions are welcome.


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=439650


not sure if you wanted the feedback here or on the bug - your description
above should be on the bug :)

anyhow no matter if you have an external description of "cordova releases"
which I reckon
will say something like:

cordova 3.4.0:
ios 3.4.0
android 3.4.0

cordova 3.4.1:
ios 3.4.1
android 3.4.0


wouldn't it be good that the tooling simply took these as advises but if
lets say an ios 3.4.2 becomes available
the tooling would still allow you to pick that up and use it no matter if
this externally defined descrption have
been updated or not ?


/max
http://about.me/maxandersen



/max
http://about.me/maxandersen

Back to the top