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 the mobile app and the binary file? How about associating multiple version of binary files with one mobile app? On Thu, May 7, 2015 at 7:16 AM, Chathura Dilan <[email protected]> wrote: > 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 > all the previous versions of the app. > > On Thu, May 7, 2015 at 12:21 AM, Dinusha Senanayaka <[email protected]> > wrote: > >> 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 <[email protected]> wrote: >> >>> ​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 use older versions of an >>> API. I.e. APIs with a version identifier in their URL. >>> >>> While the idea of having the "non-versioned" API URL always pointing to >>> the latest version of an API can be sometimes found in industry, it >>> requires a certain programming style for your clients. Do we document this >>> for our clients? >>> >>> >>> Best regards, >>> Frank >>> >>> 2015-05-04 17:55 GMT+02:00 Isabelle Mauny <[email protected]>: >>> >>>> 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. >>>> >>>> ------------------------------------------------------------------------------------- >>>> *Isabelle Mauny* >>>> VP, Product Management - WSO2, Inc. - http://wso2.com/ >>>> >>>> >>>> On Mon, May 4, 2015 at 5:35 PM, Sumedha Rubasinghe <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, May 4, 2015 at 8:30 PM, Dinusha Senanayaka <[email protected]> >>>>> 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 >>>>>> deprecated) and each app is having separate gateway endpoint with >>>>>> version. >>>>>> This result in having different urls for each versioned app. Not like the >>>>>> APIs, Apps are end user base and url should be constant while there is >>>>>> only >>>>>> latest version off app appeared on the store. >>>>>> >>>>>> So we thought of adding following changes to current model, >>>>>> >>>>>> *Current model:* >>>>>> *Publisher* >>>>>> - All versions are appeared on publisher >>>>>> - Can edit all versions except retired/depecated apps >>>>>> >>>>>> *Store* >>>>>> - All versions are appeared on store >>>>>> - Users can subscribe to any version >>>>>> >>>>>> *Gateway * >>>>>> - Each versioned app is having different url >>>>>> eg: http://localhost/app1/v1 >>>>>> http://localhost/app1/v2 >>>>>> >>>>>> >>>>>> *New model:* >>>>>> *Publisher* >>>>>> - All versions are appeared on publisher >>>>>> - Can edit only latest version >>>>>> >>>>>> *Store* >>>>>> - Only latest version is available >>>>>> >>>>>> *Gateway* >>>>>> - GW url is constructed without appending version to url >>>>>> eg: http://localhost/app1 >>>>>> >>>>>> >>>>>> *Implementation changes:* >>>>>> When new version added to an app: >>>>>> >>>>> >>>>> It should be when a new version of an app is published (not added). >>>>> >>>>> >>>>>> - Make it as the default version >>>>>> - Retire all previous versions >>>>>> - Move all existing subscriptions to new version (seamless to enduser) >>>>>> >>>>>> With new model new version creations are not visible to end user, he >>>>>> will always use the new version seamlessly. >>>>>> >>>>>> Appreciate any feedback. >>>>>> >>>>>> Regards, >>>>>> Dinusha. >>>>>> >>>>>> >>>>>> -- >>>>>> Dinusha Dilrukshi >>>>>> Associate Technical Lead >>>>>> WSO2 Inc.: http://wso2.com/ >>>>>> Mobile: +94725255071 >>>>>> Blog: http://dinushasblog.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> /sumedha >>>>> m: +94 773017743 >>>>> b : bit.ly/sumedha >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> Dinusha Dilrukshi >> Associate Technical Lead >> WSO2 Inc.: http://wso2.com/ >> Mobile: +94725255071 >> Blog: http://dinushasblog.blogspot.com/ >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > > Chatura Dilan Perera > *(Senior Software Engineer** - WSO2 Inc.**)* > www.dilan.me > -- Regards, Chatura Dilan Perera *(Senior Software Engineer** - WSO2 Inc.**)* www.dilan.me
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
