Quanto è importante la compatibilità con le versioni precedenti? [chiuso]

Question

Quando stai considerando un aggiornamento in uno strumento di sviluppo, quanto è importante per te la retrocompatibilità? Acquisteresti comunque Visual Studio 2010 se richiedesse modifiche significative al tuo codice sorgente? Qual è il punto di svolta per te in termini di compatibilità con le versioni precedenti di trading per le nuove funzionalità?

Answer 1

Mentre lo hai chiesto dal punto di vista dello sviluppatore, penso che sarebbe una domanda più interessante in riferimento al software che sviluppi. Quindi risponderò a questa domanda. :)

Hardware e software che sono retrocompatibili (e, soprattutto, compatibili con il futuro) forniscono un senso di sicurezza ai tuoi utenti, specialmente quando acquisti o aggiorni piattaforme come Windows. Se non altro, Windows è noto per la sua meticolosa attenzione alla compatibilità con le versioni precedenti. Puoi eseguire programmi scritti più di dieci anni fa su Windows Vista con solo piccoli problemi, a condizione che fossero "ben scritti". (ovvero non utilizzare API non documentate).

D'altra parte, una rigorosa attenzione alla compatibilità con le versioni precedenti può legare le mani quando si tenta di introdurre nuove funzionalità o di rivoluzionare la piattaforma. Apple sapeva di avere un SO morente e, in una delle sue mosse più audaci, acquistò NeXT e decise di trasformare NeXTSTEP nel nuovo MacOS. Una delle cose chiave che ha venduto le persone alla transizione è stato il livello compatibile con le versioni precedenti. Ancora una volta quando Apple ha deciso di passare ai chip Intel, un meccanismo per l'esecuzione di app PowerPC su Intel chiamato Rosetta, insieme agli Universal Binaries, ha permesso alle persone di spostarsi liberamente tra PowerPC e Intel senza paura di perdere le applicazioni.

Una cosa interessante è che con il passaggio a Intel l'ambiente Classic è scomparso, ma a nessuno importa davvero perché hanno avuto i 5 anni precedenti per passare da Mac OS 9. Quindi è possibile abbandonare il supporto per i sistemi legacy finché dato che hai un modo semplice per migrare al nuovo sistema e dare ai tuoi utenti il ??tempo di farlo.

Answer 2

In uno strumento di sviluppo, se non fornisce una totale retrocompatibilità con il mio codice precedente, non lo comprerò e dubito che qualcuno lo farebbe. Francamente, non ha senso. Se ho già un compilatore che funziona per costruire il mio codice sorgente in codice eseguibile che funziona per me, allora lo userò. Perché preoccuparsi di cambiare il mio codice per renderlo conforme a ciò che è ovviamente per il toolmaker non uno standard? Se impongono la modifica del codice sorgente da una versione all'altra, perché dovrebbero preoccuparsi di rendere compatibile la versione successiva?

È richiesta la compatibilità al 100% con la versione precedente. L'unica situazione in cui questo non è un requisito totale è quando i bit incompatibili sono estensioni; ad esempio modifiche API specifiche dello strumento, come plug-in Eclipse, ecc. Anche in questo caso, mi piacerebbe la compatibilità, ma mi rendo conto che non può essere completamente previsto. Ma se fornisci un'API per lo sviluppo di applicazioni / strumenti di base e non puoi preoccuparti di mantenere la compatibilità; bene, quindi, chiaramente non prendi sul serio i tuoi strumenti e non pagherò soldi seri per loro.

Answer 3

Per i progetti domestici, la retrocompatibilità non è davvero importante. Per l'ufficio / impresa, è assolutamente fondamentale.

Answer 4

Dipende dagli ambienti che è necessario supportare e dagli strumenti di terze parti che possono essere o meno compatibili.

Ad esempio, dove lavoro, abbiamo aggiornato tutti a VS2008 da VS2005 ad eccezione del nostro gruppo BI poiché gli strumenti BI di SQL Server non erano compatibili con VS2008. Una volta aggiornati, sono passati a VS2008.

Quando si osserva VS in modo specifico, tenere presente che VS2008 può essere indirizzato a .NET 2.0, .NET 3.0 e .NET 3.5. Il trucco è rendersi conto che in realtà è destinato a .NET 2.0 SP1 e .NET 3.0 SP1. Pertanto, l'aggiornamento dell'IDE non dovrebbe richiedere di apportare modifiche al codice.

Answer 5

In realtà se si sta sviluppando una piattaforma che sarà costantemente utilizzata da molti altri utenti per costruire i propri prodotti e si prevede di sviluppare l'applicazione per lungo tempo, è importante. Guarda PHP, Python, Eclipse e altri progetti open source che danno molta importanza alla compatibilità con le versioni precedenti. È anche importante quando si sviluppano servizi o altre API aperte utilizzate nell'architettura di livello n. Puoi cambiare tutte le applicazioni in un'azienda continuamente quando cambi i tuoi servizi.

Ora, se stai costruendo un'applicazione termoretraibile o un'applicazione bussiness, non è così importante, perché ogni versione è separata dai suoi predecessori.

Answer 6

Dal momento che molte modifiche stanno avvenendo nel campo del software e dell'hardware, penso che sia una buona idea essere aperti a nuove modifiche e strumenti migliori mentre si progetta la propria soluzione. Ad esempio, non avevamo processori multi core e schede grafiche di fascia alta o schede di rete negli anni '90, quindi naturalmente gli obiettivi di ottimizzazione dei compilatori e degli strumenti erano diversi. Ma allo stesso tempo Visual Studio come gli strumenti stanno facendo del loro meglio per adattarsi ai vecchi framework e app.

Penso che se non vediamo l'ora di un mondo migliore, dovremmo essere aperti a un cambiamento costante fino a quando questo settore non sarà super maturo. (Potrebbe non accadere nella nostra vita però :))

Answer 7

Definisci "modifiche significative". Ci proverei se le modifiche potessero essere fatte con una ricerca & amp; sostituire " anche se erano estesi.

Tuttavia, questo è ciò che I farebbe. Qualsiasi azienda per cui ho lavorato si opporrebbe a qualsiasi modifica al codice esistente.