From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Suhail Singh Newsgroups: gmane.emacs.devel Subject: Re: Reconsider defaults for use-package-vc-prefer-newest Date: Sun, 22 Sep 2024 16:08:04 -0400 Message-ID: <87cykvwixn.fsf@gmail.com> References: <87wmj7dftf.fsf@posteo.net> <87setvxyt6.fsf@gmail.com> <87jzf7o13b.fsf@posteo.net> <87msk3jr0u.fsf@gmail.com> <87setum5do.fsf@posteo.net> <87msk1520e.fsf@gmail.com> <87settknf1.fsf@posteo.net> <87tte8akwa.fsf@gmail.com> <878qvjaep6.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9782"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Suhail Singh , Martin =?utf-8?Q?Edstr=C3=B6?= =?utf-8?Q?m?= , "emacs-devel" , Tony Zorman To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 23 04:21:16 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ssYhP-0002O8-51 for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Sep 2024 04:21:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ssYgW-0004ee-AK; Sun, 22 Sep 2024 22:20:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssSsV-0000T4-AK for emacs-devel@gnu.org; Sun, 22 Sep 2024 16:08:19 -0400 Original-Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ssSsT-0003cb-0w for emacs-devel@gnu.org; Sun, 22 Sep 2024 16:08:19 -0400 Original-Received: by mail-qt1-x843.google.com with SMTP id d75a77b69052e-45830ff5b70so30579861cf.1 for ; Sun, 22 Sep 2024 13:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727035695; x=1727640495; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=eaWuC4ibqjDSFoHW/i4Ed9xg3WiDMju7UTokIvtiq0Q=; b=NjN4hvdq9dsIHyxaG93hbr+k0v7j359JJFSHu4cM8mtOuScte+Fo82vZxY/BTdMRY5 jbC0CH575FdRTG8E3VX5M4IWAFAsVeybdRA9Rdyif67lHcgT4fAZsU0s7xSFir7UAd3Z dDbDcJ3LbKhpatj/IokOKRKtJxx0/TKlxm/rC2zKbleq5NazgEjtd/5LmsUYoKaznoFx lHPXbSCAnXZZoI35ciSpJ3A/st6KW+gj40H+0Qj9cIV8Wanzlu6ilXksyVoME46KrMic J7mIusojxpla51hFV0Le3JwL8xe7Drxd7djPuInA+66qaEhEM3zhhCe6J909xJedWay1 j3dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727035695; x=1727640495; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eaWuC4ibqjDSFoHW/i4Ed9xg3WiDMju7UTokIvtiq0Q=; b=P4rXMF17xdiUR4Zh8D9WM6vumgaXQ8s8bjTQmebnorlyVM9ROvksDhtgxkgsoEtPuF 4qf1CVlQLQo9QUAQfL9WkZO21QJucr7Umj6B45i7UtziHHmu6jMBx2ownwhffLaqmIfh Iwxm3fwgwTw+Z1HhRG6CGE9mSmwzH8zAKMIBD1EOVlZXq0waoNJBWchEJ3bmXaM3Aa73 bJ2tEippGTw/ioxZPsipFjOtlBWOb+lbXky6M05zMzXMbNO3BV6Didcd11KEps37kn28 xYKHbi2s7NCQGE4KnAZ8beukDD+YzMYDyk7fQr3tHa5QPaD/s4L3mkyvhQwVF26SR8f1 XH/A== X-Forwarded-Encrypted: i=1; AJvYcCXZSmD90zQchtXPzhe4nQmcg5gamSO8DAOAxcIs6PFYNl54Orua3lGbzRKG+c4j3c0thWnDuaoqfuBs4A==@gnu.org X-Gm-Message-State: AOJu0Yypz9oQlLf3QgRKUSyZw2Qf5mUuf2NxokgajHv55CvinOp1EBTT viIlGgVjp59w1qO4D4bOKQWQdJ7QxkNMhvFbNgQZPIQl+flogjTk X-Google-Smtp-Source: AGHT+IE1oY7eQldgxRAucTpHNHK4lIQaUVG8DSdj3lFZGobHreIXELfjpmHYFUMJMOHp2ntZywikyg== X-Received: by 2002:a05:622a:5b92:b0:458:3a34:b7b5 with SMTP id d75a77b69052e-45b22713c66mr140573411cf.26.1727035695407; Sun, 22 Sep 2024 13:08:15 -0700 (PDT) Original-Received: from gnus ([65.94.70.53]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-45b178f37desm39835111cf.78.2024.09.22.13.08.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Sep 2024 13:08:14 -0700 (PDT) In-Reply-To: <878qvjaep6.fsf@posteo.net> (Philip Kaludercic's message of "Sun, 22 Sep 2024 15:30:29 +0000") Received-SPF: pass client-ip=2607:f8b0:4864:20::843; envelope-from=suhailsingh247@gmail.com; helo=mail-qt1-x843.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 22 Sep 2024 22:20:17 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323940 Archived-At: Philip Kaludercic writes: >>> In your case/the case of julia-mode, something like >>> >>> Other versions: 1.2.3 (melpa-stable, COMMIT MISMATCH). >>> >>> with a help annotation. >> >> Yes, something like that would have worked. Thanks in advance, if you >> do implement something of that nature. It would be useful. > > Can you test if this works: The patch you shared does /something/, but it's not clear to me what the expected behaviour is supposed to be. Could you please comment? Specifically, in the case of casual-dired (latest available on melpa-stable is 1.8.2 and I have 1.8.1 installed), I observe the following when viewing the package description: #+begin_quote Other versions: 1.8.1 (installed, COMMIT MISMATCH!), 20240917.401 (melpa). #+end_quote The commit that introduced the 1.8.1 version header isn't the same as the one that was assigned the git tag, so the above makes sense. The fact that the melpa version doesn't have a corresponding COMMIT MISMATCH seems desirable (since there's no expectation for the melpa version to correspond to the package header in any way). However, when I view the package description for casual-suite (the latest on melpa-stable is 1.6.0 and I have the same installed), I observe: #+begin_quote Other versions: 1.6.0 (melpa-stable). #+end_quote Given that the commit that introduced the 1.6.0 version in the package header is different from the one that was tagged by the git tag, I would have expected a COMMIT MISMATCH in the above as well. The absence of it seems like a bug. The situation gets weirder when I observe the description of htmlize. >From the melpa archive: #+begin_quote Other versions: 20240915.1657 (installed), 1.58 (nongnu, COMMIT MISMATCH!), 1.58 (melpa-stable, COMMIT MISMATCH!). #+end_quote >From the melpa-stable archive: #+begin_quote Other versions: 20240915.1657 (installed, COMMIT MISMATCH!), 1.58 (nongnu), 20240915.1657 (melpa, COMMIT MISMATCH!). #+end_quote >From the nongnu archive: #+begin_quote Other versions: 20240915.1657 (installed, COMMIT MISMATCH!), 1.58 (melpa-stable), 20240915.1657 (melpa, COMMIT MISMATCH!). #+end_quote Could you comment on what's happening above? >> That being said, however, based on a recent exchange, the recommended >> version that the maintainer of julia-mode wishes users download is the >> "rolling release" equivalent from melpa. I believe it is for this >> reason that they have not made a tagged release in the last four years. >> Quoting below the maintainer's response on the issue ([1]) where I >> brought this matter to their attention: >> >> #+begin_quote >> Since we do not make stable releases (effectively, it is just rolling on >> `master`, I think we should just clarify that users should use `melpa`, and if >> possible expunge the package from `melpa-stable` etc. >> #+end_quote >> >> [1]: > > If that is so, then we can also mark the ELPA package as using a > rolling-release model, i.e. the build server prepares a new tarball > every time is synchronises new commits. I believe that that would be desirable, and the accurate thing in the case of julia-mode. Could you please confirm when that change has been made. Additionally, could you please point me to where the "rolling-release model" is documented? A search for "rolling" in didn't yield any matches. -- Suhail