OK.... We need to do the 2.0.0 release ASAP, it has been dragging way too much, and I don't want to delay it because of a namespace change and do not want to call another vote for this. Let me take your votes from this thread and try to summarize the decision on this.
If I have interpreted this thread correctly, following people are for this NS change; Ruwan, Hiranya, Eric And even though after a long time there has been a huge oppose to this from the following people :-) Sanjiva, Paul, Jaeger I would consider Supun as (-0) with his statement, and Rajika to be neutral as I cannot interpret anything. With the above analysis, and the Apache way, I think we will have to revert the namespace change. I am working on the final documentation fixes for the release, once it is done I will revert the namespace change and remove the migration tool. My personal belief is that this is a step backwards and waste of a lot of work, with the migration tool and so forth. If you have any concerns over this decision please shout NOW and only NOW. Thanks, Ruwan On Mon, Nov 22, 2010 at 9:16 AM, Sanjiva Weerawarana <sanj...@opensource.lk>wrote: > On Sun, Nov 21, 2010 at 9:22 PM, Hubert, Eric <eric.hub...@foxmobile.com > >wrote: > > > Well, I think I have to agree with Sanjiva’s statement about the meaning > > of namespaces for an end user. I also do not know many people really > caring > > about namespaces as long as those namespaces are not causing any > troubles. > > Maybe one should not look at a namespace change independent of other > > changes. > > > > +1. > > > > If for whatever reason a configuration format and/or syntax has changed > > resulting in the possibility that some or even all the user’s > configurations > > will no longer work with a newer software version and users receive a > > migration tool to convert their configurations using the old format into > a > > new format, users also do not care whether there is a namespace change or > > not (as long as the migration tool works properly). > > > > API changes breaking existing custom extensions (in the case of Synapse > > primarily “mediators”) or (even more critical) changed runtime behaviour > > should normally affect end users much more. During the too long time > without > > any release since the last release of Synapse in June 2008 (so about two > and > > a half years ago) I’m pretty sure any of the above will be the case. > > > > Right, v2.0 indicates that there are major, incompatible changes in the > product. > > Namespace change is an unnecessary thing to support that as for most people > the silly namespace thing is something to gloss over (and a PITA in > general). In fact, I no longer believe that XML languages should use > namespaces at all .. only an extreme case where the language is meant to be > transparently embedded in other languages is a namespace name a necessity. > Just use unqualified XML syntax and make life easier! > > Now, if you want to support a model of ignoring the namespace I'd totally > +1 > that! Qualified names can still be used for extensions of course; that > makes > crystal clear when one is using an extension vs. the core. > > Sanjiva. > -- > Sanjiva Weerawarana, Ph.D. > Founder, Director & Chief Scientist; Lanka Software Foundation; > http://www.opensource.lk/ > Founder, Chairman & CEO; WSO2; http://wso2.com/ > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ > Member; Apache Software Foundation; http://www.apache.org/ > Member; Sahana Software Foundation; http://www.sahanafoundation.org/ > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ > > Blog: http://sanjiva.weerawarana.org/ > -- Ruwan Linton Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
