Cuando está considerando actualizar una herramienta de desarrollo, ¿qué importancia tiene para usted la compatibilidad con versiones anteriores? ¿Seguiría comprando Visual Studio 2010 si requiriera cambios significativos en su código fuente? ¿Dónde está el punto de inflexión para ti en cuanto a la compatibilidad con versiones anteriores de nuevas funciones?¿Cuán importante es la compatibilidad con versiones anteriores?
Si bien esto se lo hizo desde el punto de vista del desarrollador, creo que sería una pregunta más interesante en referencia al software que desarrolla. Así que voy a responder esa pregunta en su lugar. :)
El hardware y software que es compatible con versiones anteriores (y, lo que es más importante, compatible con el futuro) proporciona una sensación de seguridad a los usuarios, especialmente al comprar o actualizar plataformas como Windows. Si nada más, Windows es conocido por su meticulosa atención a la compatibilidad con versiones anteriores. Puede ejecutar programas escritos hace más de una década en Windows Vista con solo problemas menores, siempre que estén "bien escritos" (es decir, no use API no documentadas).
Por otro lado, la estricta atención a la compatibilidad con versiones anteriores puede atar sus manos cuando está tratando de introducir nuevas características o revolucionar la plataforma. Apple sabía que tenía un sistema operativo moribundo, y en uno de sus movimientos más atrevidos, compró NeXT y decidió hacer de NeXTSTEP el nuevo MacOS. Una de las cosas clave que vendieron personas en la transición fue la capa compatible con versiones anteriores, Classic. Nuevamente, cuando Apple decidió cambiar a los chips Intel, un mecanismo para ejecutar aplicaciones PowerPC en Intel llamado Rosetta, junto con los Binarios Universales, permitió a las personas moverse libremente entre PowerPC e Intel sin temor a perder la aplicación.
Una cosa interesante es que con la transición a Intel, el entorno Classic desapareció, pero a nadie realmente le importa porque tuvieron los 5 años previos a la transición desde Mac OS 9. Por lo tanto, es posible soltar soporte para sistemas heredados como Siempre y cuando tenga una manera fácil de migrar al nuevo sistema y brinde a sus usuarios suficiente tiempo para hacerlo.
Definir "cambios significativos". Me gustaría ir si los cambios se pueden hacer con una "búsqueda cuidadosamente & reemplazar", incluso si fueran extensas.
Sin embargo, eso es lo que haría I. Cualquier empresa para la que he trabajado rechazaría cualquier cambio en el código existente.
Depende de qué entornos necesite admitir y qué herramientas de terceros se utilicen o no como compatabile.
Por ejemplo, donde trabajo, actualizamos a todos a VS2008 desde VS2005, excepto para nuestro grupo de BI, ya que las herramientas de SQL Server BI no eran compatibles con VS2008. Una vez que se actualizaron, se actualizaron a VS2008.
Cuando se observa VS, hay que tener en cuenta que VS2008 puede estar orientado a .NET 2.0, .NET 3.0 y .NET 3.5. El truco está en darse cuenta de que realmente apunta a .NET 2.0 SP1 y .NET 3.0 SP1. Como tal, la actualización del IDE no debería exigirle que realice cambios en su código.
Dado que están ocurriendo muchos cambios en el campo de Software y hardware, creo que es una buena idea estar abierto a nuevos cambios y mejores herramientas mientras diseña su solución. Por ejemplo, no teníamos procesadores multinúcleo y tarjetas gráficas de alta gama o tarjetas de red en los 90, por lo que, naturalmente, los objetivos de optimización de los compiladores y las herramientas eran diferentes. Pero al mismo tiempo Visual studio como las herramientas están haciendo todo lo posible para adaptarse a los viejos marcos y aplicaciones.
Creo que si esperamos un mundo mejor, debemos estar abiertos a un cambio constante hasta que esta industria esté muy madura. (Puede que no suceda en nuestro tiempo de vida) :)
En genreal si está desarrollando una plataforma que será constantemente utilizada por muchos otros usuarios para construir sus propios productos, y planea desarrollar la aplicación para un mucho tiempo, entonces es importante. Vea PHP, Python, Eclipse y otros proyectos de código abierto que le dan mucha importancia a la compatibilidad con versiones anteriores. También es importante cuando se desarrollan servicios u otras apis abiertas utilizadas en la arquitectura de n niveles. Puede hacer que todas las aplicaciones en una empresa se quiebren todo el tiempo cuando cambie sus servicios.
Ahora, si está creando una aplicación de contracción o una aplicación empresarial, entonces no es tan importante, ya que cada versión está separada de sus predecesoras.
Para proyectos en el hogar, la compatibilidad con versiones anteriores realmente no es importante. Para la oficina/empresa, es absolutamente crítico.
En una herramienta de desarrollo, si no proporciona compatibilidad total hacia atrás con mi código anterior, no lo compraré y dudo que alguien lo haga. Francamente, no tiene sentido. Si ya tengo un compilador que trabaja para construir mi código fuente en código ejecutable que me funciona, entonces lo usaré. ¿Por qué molestarse en cambiar mi código para cumplir con lo que obviamente para el fabricante de herramientas no es un estándar? Si fuerzan los cambios del código fuente de una versión a otra, ¿por qué se molestarían en hacer compatible la próxima versión?
100% de compatibilidad con versiones anteriores es un requisito.La única situación donde esto no es un requisito total es cuando los bits incompatibles son extensiones; es decir, cambios API que son específicos de la herramienta, como los complementos de Eclipse, etc. Incluso entonces, me gustaría la compatibilidad, pero me doy cuenta de que no se puede esperar por completo. Pero si proporciona una API para el desarrollo de aplicaciones/herramientas básicas, no se puede molestar en mantener la compatibilidad; Bueno, entonces, claramente no hablas en serio acerca de tus herramientas, y no pagaré mucho dinero por ellas.
Sospecho que realmente no lo dices en serio como lo pones. Por ejemplo, C# 2 no es 100% compatible con C# 1. Está cerca, pero no es 100%. Por su lógica, nadie debería haber ido con VS2005 o VS2008. –
También estoy en desacuerdo. Ayudé a varias personas a migrar de eVC a Studio y el código que "funcionó" bajo eVC ni siquiera se compilará en Studio porque el compilador ha mejorado mucho. Una vez compiladas, los tiempos de ejecución más recientes también encontraron muchos problemas con el código. Entonces, incluso después de semanas de trabajo, valió la pena. – ctacke
¿Podría usted, como un tipo con experiencia, explicarme por qué no se trata de una publicación wiki de la comunidad? – badbadboy
Porque es una pregunta legítima? Community Wiki no es aplicable a todo, y no culpo a kogus por no optar por él. –