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 <[email protected]> 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 the code review [1], it was suggested to adopt "published version" > concept to implement this feature. > > Adopting the "published version" approach > > - Only one version of a particular web app is published and other > versions are marked as unpublished. (eg: 1.0.0v, 2.0.0v & 3.0.0v are > "unpublish"ed and 4.0.0v is "publish"ed) > - User can access the published version of a web app without version > in the URL and accessing a web app using a URL with a version is blocked. > (eg: user can access the web app using http://localhost:8280/eg/ URL, > but not using http://localhost:8280/eg/1.0.0/ which is forbidden) > - Publisher can published an unpublished version of a web app form the > UI. When the "publish" button is pressed, that version will be published > and other versions will be unpublished. (eg: 1.0.0v, 2.0.0v & 3.0.0v are > unpublished and 4.0.0v is published; publisher can mark 3.0.0v as published > and other versions 1.0.0v, 2.0.0v, 4.0.0v are automatically unpublished) > - When publishing a particular version of a web app, subscriptions > from the previous published version are automatically moved to the new > published version. > > > > [1] Invitation: [Code Review][AppM] Improving app versioning support in > A... @ Mon May 18, 2015 2:30pm - 3:30pm ([email protected]) > > Thanks & Regards. > > > On Thu, May 7, 2015 at 4:02 PM, Sajith Ariyarathna <[email protected]> > wrote: > >> 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 doesn't want >> to make the new version *default* then he/she can uncheck it. >> >> Thanks & regards. >> >> On Thu, May 7, 2015 at 7:28 AM, Chathura Dilan <[email protected]> >> wrote: >> >>> 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 >>> >>> >> >> >> -- >> Sajith Ariyarathna >> Software Engineer; WSO2, Inc.; http://wso2.com/ >> mobile: +94 77 6602284, +94 71 3951048 >> > > > > -- > Sajith Ariyarathna > Software Engineer; WSO2, Inc.; http://wso2.com/ > mobile: +94 77 6602284, +94 71 3951048 > -- Sajith Ariyarathna Software Engineer; WSO2, Inc.; http://wso2.com/ mobile: +94 77 6602284, +94 71 3951048
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
