Guys whats the verdict on this discussion ? Having a patch directory within the app seems to be a fine idea, which does not effect the platform patching or raise depsyc complications. Shall we come to a conclusion and implement this. IMO this is vital to all the products that has jaggery applications.
Regards, /Nuwan On Thu, Jan 30, 2014 at 12:19 AM, Chan <[email protected]> wrote: > > > On Thursday, January 30, 2014, Tanya Madurapperuma <[email protected]> wrote: > >> >> >> >> On Wed, Jan 29, 2014 at 10:49 AM, Chan <[email protected]> wrote: >> >> >> >> On Wed, Jan 29, 2014 at 10:43 AM, Chan <[email protected]> wrote: >> >> >> >> >> On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha <[email protected]>wrote: >> >> >> >> >> On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara <[email protected]> wrote: >> >> >> >> On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez <[email protected]> wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara <[email protected]> wrote: >> >> Hi All >> >> >> On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera <[email protected]> wrote: >> >> The problem ultimately boils down to this common scenario: >> >> a) A customer has a Jaggery app in their environment. >> b) Some UI (images, css, headers, ect.) is customized >> c) Now they find a bug and ask for a patch >> >> >> +1, the issue here is all others replied here against patching a jaggery >> app is because you think of a jaggery app as a "hello world" web app. But >> you should look at the jaggery code in products like APIM / AppFac / UES / >> ES / MDM. In all these products Jaggery app is the place that has the major >> business logic. In these products Carbon is just the hosting environment. >> These are full fledge applications that does all kinds of things, generate >> meta data, has its own configurations etc, and when we find a minor issue >> we cannot ask people to replace the entire app and reconfigure every thing >> from the beginning. >> >> Just try the application developers shoes for a moment here and get out >> of the midleware developer mindset; Imagine we have developed an >> application and thats our main product. Now how do you fix problems in this >> product ? will you be shipping new versions of the product always when you >> find an issue ? If that is the case we will be shipping new versions of AS >> every day ;) >> >> Also when there is a requirement we should not think about how it can be >> squeezed into the existing model with minimum headache. We should find a >> comfortable solution for the users not something comfortable to implement. >> >> >> The requirement is to fix bugs in apps. The requirement is not, support >> patching of webapps. The solution is to update the app through patch fileif >> the app is >> uses a textual scripting language, or redeploy changed or a new version, >> if the app is in a compiled/binary/bytecode form. >> >> >> +1, that should work, but we nee >> >> AFAIU this solution is not feasible as we have to maintain a separate git >> repo for each customer. >> > As far as I know - we do maintain code bases for customers. Plus > maintaining git repos for customers is realistically not a hard thing to do > cause everything is scriptable in git. > >> It will become an issue when the number of customers grow. And also >> customers with lesser developer knowledge will face issues in resolving >> conflicts in merging etc. >> > If customers customize our jaggery apps which they will definitely do - > they will version control it anyway and most probably they will use git. > > >> >> Patches approach is nice but thinking from an Application Developer stand >> point version controlling is the best way to handle this type of patches. >> Food for thought I guess. >> >> [1] - https://devcenter.heroku.com/articles/git >> >> >> >> On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez <[email protected]> wrote: >> >> Cluster-wide patch distribution will be handle by the Operations Center. >> >> Azeez >> >> >> On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha <[email protected]>wrote: >> >> >> >> >> -- >> Tanya Madurapperuma >> > > > -- > Chan (Dulitha Wijewantha) > Software Engineer - Mobile Development > WSO2Mobile > Lean.Enterprise.Mobileware > * ~Email [email protected] <[email protected]>* > * ~Mobile +94712112165 <%2B94712112165>* > > * ~Website dulithawijewantha.com <http://dulithawijewantha.com/> * > > * ~Blog blog.dulithawijewantha.com > <http://dulichan.github.io/chan/>* > * ~Twitter @dulitharw <https://twitter.com/dulitharw>* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Thanks & Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. * *lean . enterprise . middleware | http://wso2.com <http://wso2.com> * *blog : http://nuwanbando.com <http://nuwanbando.com>; email: [email protected] <[email protected]>; phone: +1 812 606 7390 * <http://www.nuwanbando.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
