Come posso rilasciare con garbo il supporto per il vecchio emacsen nel mio pacchetto elisp?

Question

Mantengo un pacchetto emacs abbastanza ben utilizzato (ido-ubiquitario) e nella prossima versione ho intenzione di rilasciare il supporto per Emacs 23 e successivi. Le persone che usano Emacs 23 e versioni successive potranno continuare a utilizzare la versione corrente del mio pacchetto.

Tuttavia, non voglio che gli utenti di Emacs 23 eseguano l'aggiornamento tramite ELPA o git o qualcos'altro e finiscano con la nuova versione che non è compatibile con i loro emacs. Esiste un modo generalmente accettato di gestirlo con garbo? Ho qualche scelta per rinominare la nuova versione in "ido-ubiquitous-ng" o qualcosa del genere?

Answer 1

ELPA/package.el

per impedire gli aggiornamenti via package.el, aggiungere la dipendenza speciale (emacs "24.1") alla lista Package-Requires. Vedere Library Headers nel Manuale Emacs Lisp, nella descrizione dell'intestazione Package-Requires::

[...] Il codice del pacchetto definisce automaticamente un pacchetto chiamato ‘emacs’ con il numero di versione del Emacs attualmente in esecuzione. Questo può essere usato per richiedere una versione minima di Emacs per un pacchetto.

Il package.el che viene distribuito indipendentemente per Emacs 23 e sotto fa non fornire questo pacchetto speciale. Pertanto, qualsiasi tentativo di installare il pacchetto su Emacs 23 non riuscirà con un messaggio che si lamenta del fatto che "emacs" non è disponibile per l'installazione, lasciando la vecchia versione compatibile in posizione.

Tuttavia, quando si utilizza questo, essere pronti a gestire i reclami degli utenti di Emacs 24. Molti utenti a quanto pare non cancellano il loro vecchio package.el durante l'aggiornamento a Emacs 24. Così la vecchia package.el ignora il nuovo built-in uno, leading to spurious errors on installation.

---

ELGet

non so Elget. Probabilmente chiedere l'aiuto dell'autore in questa materia.

---

sottomoduli Git, tarball e altri legacy metodi

non credo, che si può veramente prevenire aggiornamenti, se gli utenti installano il pacchetto in un modo legacy (ad esempio moduli di Git, pacchetti di distribuzione, eccetera.). Puoi solo presentare un reclamo dopo il che il tuo pacchetto è stato aggiornato, il che è probabilmente troppo tardi, perché il codice incompatibile è già presente.

È possibile scegliere di aggiungere un controllo versione esplicito, con un error dettagliato. Considero questo superfluo, però. Se si utilizza veramente Emacs 24, verranno utilizzate funzioni incompatibili, pertanto il pacchetto non verrà caricato correttamente, indipendentemente dal fatto che lo si impedisca o meno esplicitamente. Quindi, salva te stesso di codice superfluo :)

---

TL; DR (+ esperienza personale)

Prima di tutto, si prega di non rinominare il pacchetto. Pochi utenti possono seguire le notizie su ogni pacchetto installato. Pertanto, molti utenti non si rendono immediatamente conto che il pacchetto è stato rinominato e continuano a utilizzare una versione obsoleta senza preavviso o avviso.Effettivamente, potresti punire gli utenti di Emacs 24 del tuo pacchetto.

Aggiungere la dipendenza speciale per impedire aggiornamenti accidentali tramite package.el. Aggiungi una documentazione importante, che il tuo pacchetto richiede Emacs 24, come nella prima sezione del tuo file Leggimi di Github. Quindi, lascia riposare la questione. Qualunque altra cosa è probabilmente più fastidiosa che valga la pena.

Nel mio personale esperienza, gli utenti di Emacs non sono stupidi (beh, almeno la maggioranza non lo è). Loro leggono la documentazione. Comprendono la documentazione.

Gli utenti di Emacs 23 sanno che il loro Emacs è obsoleto. Molti di loro si aspettano incompatibilità e rotture. Se il pacchetto si rompe improvvisamente per loro, cercheranno consigli su Github, realizzeranno che il pacchetto non è più disponibile per Emacs 23 e torneranno all'ultima versione funzionante o (si spera) aggiorneranno i loro Emacs.