From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Cross Subject: Re: [ANN] org-ql 0.4 released Date: Sat, 25 Jan 2020 11:24:43 +1100 Message-ID: <87d0b8v0vo.fsf@gmail.com> References: <87ftg5vf70.fsf@alphapapa.net> <87blqt2ego.fsf@jaunder.io> <87blqsv3om.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:43748) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iv9Fs-00034Q-Iq for emacs-orgmode@gnu.org; Fri, 24 Jan 2020 19:24:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iv9Fq-00089h-QY for emacs-orgmode@gnu.org; Fri, 24 Jan 2020 19:24:52 -0500 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]:46312) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iv9Fq-00088h-KJ for emacs-orgmode@gnu.org; Fri, 24 Jan 2020 19:24:50 -0500 Received: by mail-pf1-x443.google.com with SMTP id n9so1872049pff.13 for ; Fri, 24 Jan 2020 16:24:50 -0800 (PST) In-reply-to: <87blqsv3om.fsf@alphapapa.net> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Adam Porter Cc: emacs-orgmode@gnu.org I don't disagree with most of what you write. I do think a big part of the problem is inconsistency and poor practices by some maintainers which is at the hart of the issue. Sometimes it seems that package maintainers put too much emphasis on getting the latest package out and forget about the stability and dependencies that users have. All of this leaves me wondering why the ELPA system doens't adopt a semantic versioning scheme and configure the repositories to keep/maintain previous versions. Emacs was very late to the whole 'package' concept and it is a little disappointing that more time wasn't invested in understanding the challenges and solutions implemented by other systems like deb, rpm, CPAN, Java, ruby, python etc. There is little unique to the Emacs environment that other environments haven't had to resolve one way or the other. What would be good is an approach based on sematic versioning similar to npmjs.com, maven, clojars and other packaging systems. Semantic versioning won't solve all the issues. The lack of namespaces or ability of libraries to depend on specific versions of a library are both significant challenges. However, a semantic version does provide more information than something like version 20200123, which just tells me the release date. At least with complaint semantic versions I can have a better idea as to whether the changes are just a bug fix, an enhancement or major API changes that may break existing dependencies. Tim Adam Porter writes: > Michael Alan Dorman writes: > >>> Hi friends, >>> >>> FYI, I've released org-ql 0.4. It includes many improvements since 0.3. >>> >>> https://github.com/alphapapa/org-ql >> >> It would be nice if you could do a stable release of org-super-agenda so >> that it could be installed from melpa-stable... > > Comments like yours lead me to the conclusion that MELPA Stable needs to > be abolished. I have been a proponent of the idea of MELPA Stable, so I > don't say that lightly. > > I'll assume that you don't know what the technical issues are and offer > an explanation. Briefly: > > + MELPA Stable is nothing like what one might assume it's intended to be > like, e.g. Debian Stable or Debian Testing. It provides none of the > benefits that Debian Stable and Testing provide. > > + MELPA Stable is, just like "regular" MELPA, a "rolling" collection of > packages developed without any coordination between maintainers. > > + The only difference is that MELPA Stable contains whatever versions of > packages that their maintainers have decided to tag with a version > number, rather than the latest commit to the master branch. These > versions are not necessarily better, more stable, more reliable, or > more trustworthy than the untagged versions which appear in "regular" > MELPA. > > + Due to the lack of coordination between dependencies and their APIs, > version conflicts and breakage are a regular occurrence. For example, > if package A depends on package B, and package B makes an API change > and tags a new MELPA Stable release, users of package A's MELPA Stable > version will see package A cease to work properly until package A, not > only commits a fix, but tags a new MELPA Stable version containing the > fix. Since packages A and B do not share the same development > schedule, it is likely that their tagged-version release schedules > will not synchronize well. > > If you are familiar with Debian, imagine if any upstream changes were > automatically pushed to Testing despite any freeze that might be in > place. It would be virtually impossible to complete a freeze and make > a new stable release, and Testing and Stable would cease to be useful, > leaving only Unstable as a usable target. This is the situation > between "regular" MELPA and MELPA Stable. > > For my packages, I tag stable versions for a few reasons: > > + To help users track changes in the changelog. > > + To help me separate new, possibly bug-introducing changes from > working, debugged code. > > + To help packagers in systems like Debian and Guix, who package stable > versions of some Elisp packages--and who, in so doing, take > responsibility for breakage. > > Now, I sympathize with not wanting to be vulnerable to potential > breakage caused by the uncoordinated release of changes to packages on > "regular" MELPA. That is a real problem. But the solution is not to > use MELPA Stable. The solution is to take charge of what packages you > upgrade and when, rather than being at the mercy of whatever commits > happen to be in MELPA at the moment. > > For myself, I commit the ~/.emacs.d/elpa directory to Git with the rest > of my config, and I upgrade packages intentionally. If breakage > happens, I can easily revert and deal with it later. Other users use > alternative package managers, like Borg or Straight or Quelpa, which > pull changes directly from Git repos and allow pinning to commits, tags, > etc. > > So, for yourself, I can only recommend that you abandon MELPA Stable and > install packages by other means. If you don't have the time or > inclination to redo your whole config like that, then just use something > like Quelpa to install the current version of org-super-agenda directly. > It's a couple lines of use-package in your config, and you can upgrade > it manually from then on, e.g. with > . > As always, your Emacs config is up to you. > > Now, I'm off to to the discussions on MELPA's tracker to add my vote to > abolish MELPA Stable, or to at least allow packages to opt-out of it. -- Tim Cross