Hi All,
I have implemented this feature for the next release. For more details
please see document [1].
Thanks & regards.
[1]
https://docs.google.com/a/wso2.com/document/d/1TfXdUXaQqvGFEnGO1JIaQGAJ4BQjAMX6Q_yVLThLcCk/edit?usp=sharing
On Mon, May 18, 2015 at 7:06 PM, Sajith Ariyarathna
wrote:
This "default version" concept is adopted form APIM. However it is not
quite suitable for APPM in this scenario. Because our main goals in APPM
are to hide the web app version form user and allowing user to access only
one version of the web app (latest or the version decided by the
publisher).
In
Regarding web apps,
I think instead of forcefully marking the newest version as the default
one, giving that option to user will be a better approach. For example, we
can add a check box *☑ **Make this version default* to the "Add New
Version" UI. This checkbox is checked by default, so if user do
As far as mobile apps concern, one version is associate with one mobile
binary file. If a user want to upload another version of the binary, he
needs to create a new mobile app from the scratch. Those binary files could
be updated very frequently.
What do you think about one to one relationship of
Also, Web apps and specially mobile apps are updated frequently. If we show
all the apps versions in the publisher it would be a really a mess. We
should be able to group app versions and and only show the latest version
in the publisher. Once the user click on the app, he should be able to view
al
Hi Frank,
This is for web-apps and mobile-apps, not for APIs. Unlike the APIs, since
application itself is the one end user consumes,there can't be any issues
like that.
Regards,
Dinusha.
On Tue, May 5, 2015 at 9:53 PM, Frank Leymann wrote:
> Sumedha,
>
> does that mean that a client cannot
Sumedha,
does that mean that a client cannot use backward versions of an API? I.e.
that a client may break if it just uses http://localhost/app1 and gets a
new version of a response that it cannot process? I may have misunderstood
the mail-thread...
To avoid this, clients should be allowed to u
Dinusha,
If the latest is broken, there will be an unpublish action. @ that point we
can make the previous version the default.
On Tue, May 5, 2015 at 9:57 AM, Dinusha Senanayaka wrote:
>
>
> On Tue, May 5, 2015 at 8:38 AM, Srinath Perera wrote:
>
>> However, if I find out my latest version is
On Tue, May 5, 2015 at 8:38 AM, Srinath Perera wrote:
> However, if I find out my latest version is broken .. can I mark the one
> before it as my default? This is a one of the key requirements of HA.
>
Haven't thought of this, but yes we could provide a option in publisher UI
to forcefully make
However, if I find out my latest version is broken .. can I mark the one
before it as my default? This is a one of the key requirements of HA.
On Mon, May 4, 2015 at 10:04 AM, Sumedha Rubasinghe
wrote:
> In API-M, you need to explicitly mark a version as the default one. Then
> only it will work
In API-M, you need to explicitly mark a version as the default one. Then
only it will work.
Here we are suggesting to forcefully mark the last published version as the
default so that an app can be accessed without giving the version.
On Mon, May 4, 2015 at 9:25 PM, Isabelle Mauny wrote:
> I th
I thought this was the default behavior since it's already working like
this in API- M so +1 to make the version change transparent to users. When
you say next release, you mean 1.1.0 ? or 1.0.0.
Isabelle.
-
*Isabe
On Mon, May 4, 2015 at 8:30 PM, Dinusha Senanayaka wrote:
> Hi,
>
> We thought of doing some changes to current versioning support in App
> Manager. Current model is similar to "Create new version" functionality in
> API Manager. All versions are appeared on store (unless previous version is
> de
Hi,
We thought of doing some changes to current versioning support in App
Manager. Current model is similar to "Create new version" functionality in
API Manager. All versions are appeared on store (unless previous version is
deprecated) and each app is having separate gateway endpoint with version
14 matches
Mail list logo