On Mon, Nov 28, 2011 at 6:14 PM, Justin Deoliveira <[email protected]>wrote:
> In terms of migration I think it would be ok to drop the data component of
> the package... however as you say what happens next time we want to
> rewrite... go back to data? What about keeping the same package and just
> telling users to try out the new one you can't have the old jar around? Too
> harsh?
It would be a bit unprecedented and a bit annoying to handle.
So far these upgrades have been handled in such a way that you can opt out
by setting a switch
(think jdbc upgrade, shapefile renderer phasing out) and I'd like to keep
it that way,
so that people are somewhat eager to try because the process is simple and
safe.
Jody's suggestion seems to be a good one, we could indeed have a flag in
the factory
that enables/disables the new store. This would allow us to test the thing
a bit
before the 8.0 release and if it works fine for most people we can just
move the old code in
unsupported for those that have troubles migrating to the new one
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
-------------------------------------------------------
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
