No hemos acabado de migrar una solución desde Visual Studio 2008 o 2010 a la ¿última? versión 2012 y ya tenemos aquí Visual Studio 2013 (en preview… sí…, pero ya está aquí). Pero es que además se acaba de publicar también el Update 3 de la 2012.
Es cierto que los «updates» no suponen una ruptura que generen mayores problemas, incluyendo revisiones de algunos de los framework que van con el paquete, o incluso añadir funcionalidades completas (véase SignalR, creo que con el update 2 …pierdo la cuenta). Esto es así, y todo lo que sea agregar está muy bien y se agradece. Sin embargo el cortísimo ciclo de vida con las versiones mayores realmente crea problemas; cuando además de agregar, se eliminan elementos o se rompe la compatibilidad, las dificultades aparecen rápidamente.
Hay equipos de programación que se dedican a mantener aplicaciones de muy largo ciclo de vida, incluso de más de 10 años; proyectos complejos, con varios productos interrelacionados, dependientes unos de otros, con tecnologías diversas, y con soluciones (SLN) algunas de más de 25/30 proyectos, llegando a sumar fácilmente más de 100 proyectos (PROJ) en total. Por definición, la administración de este tipo de aplicaciones es en sí mismo un trabajo muy importante y de cierta complejidad; plantearse la migración es un auténtico reto y merece un análisis detallado, requiriendo de cierta experiencia.
Por otra parte, pero no menos importante, desde el punto de vista personal te sientes inferior cuando no paras de ver a los gurús del desarrollo twittear que ya han instalado la última versión, aunque esté en «Preview», hablando maravillas de las nuevas características y dando ejemplos a cada cual más interesante. Estos valientes, lo instalan en producción, con proyectos reales… y el mismo día en que Microsoft publica la release ¡sí, no creas que tienen miedo!… ¿para qué esperar a la RTM?
Para que este post sirva de algo más que un desahogo, un poco de historia con las versiones más recientes de Visual Studio y las fechas de publicación (sólo versiones RTM):
- Visual Studio 2005. Octubre 2005 en inglés, febrero 2006 en español.
- Service Pack 1. Junio 2007
- Visual Studio 2008. Noviembre 2007 en inglés, febrero 2008 en español.
- Service Pack 1. Agosto 2008
- Service Pack 2… el inacabado… se estuvo hablando durante meses y meses pero finalmente no apareció
- Visual Studio 2010. Abril 2010
- Service Pack 1. Abril 2013
- Visual Studio 2012. Agosto 2012.
- Update 1 en noviembre 2012
- Update 2 en abril 2013
- Update 3 en julio 2013
- Visual Studio 2013 Preview junio 2013
Con el penúltimo paso de 2010 a 2012, Microsoft ha hecho un esfuerzo para hacer compatibles los proyectos, pero el cambio no sale gratis: por ejemplo desaparecen los proyectos clásicos de instalación; simplemente no los carga el explorador de proyectos. Ahora parece que con la versión 2013 nos espera algo similar con los proyectos de Unit Testing… ya veremos.
Todo esto viene a concluir que Microsoft, en mi opinión, se pasa un poquito con tanta versión, dejándote anticuado en tres o cuatro años como mucho. Un entorno cómo Visual Studio es lo suficientemente complejo y sofisticado como para que sus usuarios, entre los que me incluyo, puedan amortizar la gran cantidad de tiempo dedicado a conocer todas sus características y, en definitiva poder explotar toda su funcionalidad. Esto no quiere decir que el entorno no deba actualizarse y enriquecerse convenientemente; esto es absolutamente necesario, pero siempre cuidando mucho muchísimo al ecosistema de desarrolladores que trabajan con él.
Es cierto que parece que Microsoft ha entendido esto, pero ¡sólo a medias! Por ejemplo, desde la versión 4.0 de .NET se decidió que las siguientes versiones de Entity Framework no irían en correlación; de hecho al poco tiempo aparecía EF 4.1 para no tener que esperar a .NET 4.5. Con otras tecnologías como ASP.NET MVC pasará lo mismo. Esa es la dirección correcta, pero habría que ir más lejos… ¡¡¡hay que incluir en esta separación a .NET completito!!!
Dicho todo esto, también es de justicia decir que probablemente Visual Studio es el mejor entorno de desarrollo que existe en el mercado,y con diferencia, aunque también podríamos hablar largo y tendido de los paquetes que se han ido quedando en el tintero, y a los que Microsoft simplemente les ha dado «pasaporte» dejando a muchos de sus desarrolladores con tres palmos de narices: véase VSTO o el soporte para Molex.
Esperemos que Microsoft escuche un poco más a la comunidad de sus desarrolladores.