emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: [ANN] org-ql 0.4 released
Date: Fri, 24 Jan 2020 18:59:15 -0600	[thread overview]
Message-ID: <877e1guzzw.fsf@alphapapa.net> (raw)
In-Reply-To: 87d0b8v0vo.fsf@gmail.com

Tim Cross <theophilusx@gmail.com> writes:

> 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.  

The problems you identified in the first paragraph are why the solution
identified in the second paragraph doesn't work (for this case; I like
SemVer in general).

> 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.

Yes, and that's why I like it, too.  But we can't make other developers
use it.  Even if MELPA required SemVer-like numbering, nothing would
stop package maintainers from incrementing major-only version numbers.
It's their code.

Developing with proper use of semantic versioning is a discipline that
requires extra diligence.  It's rarely more fun, and for most Emacs
packages, it's not worth the trouble.  Most packages are dependents
rather than dependencies, leaves at the ends of the branches, and they
can be freely upgraded without breaking anything else.  Most packages'
interoperability with other packages is minor.

If SemVer were required, MELPA would probably have 5-10% of the packages
it does today.  The lax, welcoming approach used by MELPA has drawbacks,
but it also has tremendous benefits, and I think it's to credit for much
of the vibrancy of the Emacs package "ecosystem" and community today.

The problem I'm writing about here is that users' perception of MELPA
Stable doesn't match the reality.  Discussions about how to change MELPA
Stable and MELPA versioning for the better have been going on for years.
Ultimately that doesn't matter, because package authors can do whatever
they want.  We should help users understand and accept the technical
reality--and MELPA Stable misleads them, so it should be removed.  As I
posted in my proposal on the MELPA tracker, we can pursue better
technical solutions then, ones that may be more in line with the
limitations of the platform.

If you're interested in the topic, please join the discussions on the
MELPA tracker.

  reply	other threads:[~2020-01-25  0:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24  1:03 [ANN] org-ql 0.4 released Adam Porter
2020-01-24 13:04 ` Michael Alan Dorman
2020-01-24 23:24   ` Adam Porter
2020-01-25  0:24     ` Tim Cross
2020-01-25  0:59       ` Adam Porter [this message]
2020-01-25  3:08     ` Michael Alan Dorman
2020-01-25  8:08       ` Adam Porter
2020-04-22 19:31         ` David R
2020-04-23  2:47           ` Adam Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877e1guzzw.fsf@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).