From: Dmitry Marakasov <amdmi3@amdmi3.ru>
To: Paul Smith <psmith@gnu.org>
Cc: bug-gnulib@gnu.org, Bruno Haible <bruno@clisp.org>
Subject: Re: Versioned releases
Date: Thu, 4 Jun 2020 23:11:20 +0300 [thread overview]
Message-ID: <20200604201120.GG11553@hades.panopticon> (raw)
In-Reply-To: <1b0a905eb02c45c8d0c32aff60b05adf989cbd97.camel@gnu.org>
* Paul Smith (psmith@gnu.org) wrote:
> Regarding the format of the version:
>
> First, semver is not right for gnulib. The entire concept behind
> semver and similar versioning schemes is to use a version string to
> describe compatibility guarantees between different versions. That's
> (IMO) completely inappropriate for a source-only package like gnulib.
Why, that's precisely what semver is useful and was designed for.
It's MAJOR.MINOR.PATCH - if you break API, bump MAJOR, if you introduce
new feature, bump MINOR, otherwise bump PATCH.
So as a consumer I may just require e.g. version >=1.2.3 <2, and expect
it to be API-compatible and have all the features my code requires. With
that, library code may be safely (even automatically) updated to the
latest 1.x version, be it a systemwide package maintained by someone
else, or a bundled code/subrepository, and consumer code will not break,
yet having all the latest features/fixes from the library.
> I think the Git SHA is the single most critical element and must be
> included. However, it's not too informative unless the user has the
> Git repo.
>
> My recommendation would be to automatically add a tag once a month
> (say) to the gnulib Git repo with the date, and then use the "git
> describe" output as the version. This gives an easily-comparable
> version string with all the info needed.
This complicates the format, as SHAs are never appropriate in the
verions, for they are not monotonic and alphabetic characters are not
compatible with all package managers. Someone may include them, some may
omit them, and we'll end up with incompatible versioning schemes again.
If you're going to introduce a version, please be sure it's the same
being a tag or embedded in the source. You may as well embed git commit
or `git describe` output, but it should be clearly separated from the
version.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru ..: https://github.com/AMDmi3
next prev parent reply other threads:[~2020-06-04 20:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 15:41 Versioned releases Dmitry Marakasov
2020-06-04 18:19 ` Bruno Haible
2020-06-04 19:29 ` Dmitry Marakasov
2020-06-04 21:29 ` Bruno Haible
2020-06-05 12:15 ` Paul Smith
2020-06-04 19:46 ` Paul Smith
2020-06-04 20:11 ` Dmitry Marakasov [this message]
2020-06-04 21:16 ` Paul Smith
2020-06-04 23:10 ` Bernhard Voelker
2020-06-04 23:24 ` Bruno Haible
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200604201120.GG11553@hades.panopticon \
--to=amdmi3@amdmi3.ru \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=psmith@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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).