On Mon, May 16, 2011 at 4:49 PM, Justin Deoliveira <jdeol...@opengeo.org> wrote: >> If they are not recent we could just remove them from 2.1.x and trunk and >> leave them on 2.0.x? > Yup, that works too. Although if we want to keep things a little cleaner > moving forward we might consider not including any community modules when we > fork out a stable branch.
What about those modules that are trying to graduate, and those that we added to the night build? I'm afraid many people would just not try them out if they are associated only to a trunk nightly build, you'd mix a new module growing up with a known to be unstable GS build. >> >> If they are recent I guess we could leave them only on trunk or >> something like that, >> and clean them up later if it needs be? >> What worries me about moving them "outside" is that they lose the >> connection with >> the branch they were meant to be buildable into. > > Fair enough. No strong opinion on my side. I was pretty conservative about > marking modules with interest so they'll stay in community for now. Cool Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
