Re: Reconsider defaults for use-package-vc-prefer-newest

[Suhail Singh <suhailsingh247@gmail.com>]

Philip Kaludercic <philipk@posteo.net> writes:

>>> I wonder if indicating a "commit mismatch" for remote packages might
>>> be interesting (we explicitly don't want this for local packages,
>>> e.g. packages installed via package-vc).
>>
>> Depending on the logic of "commit mismatch" detection, that may be
>> sufficient.  Could you describe what you had in mind?
>
> 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.

>>> Could you perhaps elaborate on why you consider this to be a bug?
>>
>> To be clear I meant that it's a bug in the remote package.
>
> Perhaps I am being pedantic, but this sounds like a mistake, not a /bug/
> in the code itself.

I meant that I considered it a software defect in the packaging process.
It might have been more accurate to term it a bug in the remote
package's packaging process.  In any case, the implication wasn't that
it was a bug in the remote package's source code.  I hope it's clearer
now.

>> Specifically, in the case of julia-mode, it was a bug for it to have
>> introduced the 0.4 package header in a commit that was different from
>> the one that was tagged as 0.4.
>
> Do you know which of the two is correct?  In cases like these, it sounds
> like one should contact the maintainers to remind them that they
> shouldn't repeat the same issue in the future.

Given that the change that was added between the commit that updated the
package header and the commit that corresponded to the git tag was a
fairly important bug-fix, I believe the intended revision (for 0.4) was
the one corresponding to the git tag (i.e., the more recent commit and
the one available via melpa-stable).

In general, for packages with a git repository that have a presence
outside of GNU and NonGNU ELPA, I believe the version corresponding to
the "git tag" to be more closely aligned with the maintainer's intent.

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]: <https://github.com/JuliaEditorSupport/julia-emacs/issues/212#issuecomment-2328150198>

-- 
Suhail