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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
