> I also don't think that this is a problem with semantic versioning: the
> boost people use what we might call "anti-semantic versioning," but they
> still wreak havoc with the world. The problem isn't that semantic
> versioning breaks everything, the problem is that
x27;s test suite.
I feel like this is, as my advisor used to say "reducing this to a
previously unsolved problem"!
In my experience, testing is even less well-used than semantic
versioning!
Anyway, none of this is going to make me keep semantic versioning
support out of ASD
>>>
>>>> I've opened an issue in the SemVer github repo:
>>>> https://github.com/semver/semver/issues/771
>>>> (Don't want to repeat this explanation over and over in many discussions).
>>>>
>>>>
>>>
>>
ng (increasing the version number simply
because
you can) and is not a problem semantic versioning is trying to solve.
What
it *does* try to solve is that the engineers working on the software
can
see the problems coming.
I disagree, in the example authentication-1.1.2 upgrades a depend
good ones can fix": the issue
> you raise is bad engineering (increasing the version number simply because
> you can) and is not a problem semantic versioning is trying to solve. What
> it *does* try to solve is that the engineers working on the software can
> see the problems coming.
On Fri, Nov 19, 2021 at 10:15 PM Erik Huelsmann wrote:
>
>
> Maybe we need a way for a system declaration to indicate whether its
> version adheres to semver or not?
>
Anyway, the discussion seems to have drifted away from the original
question whether versions should be sorted using the semver
On Fri, Nov 19, 2021 at 10:08 PM Stelian Ionescu wrote:
> It shows that semantic versioning is a bad idea
>
It's not a bad idea. It's badly executed. If humanity would be forbidden to
start executing any good ideas because they will be executed badly, we
wouldn't be doing
It shows that semantic versioning is a bad idea unless you have automatic ways
of diffing an API between two versions (such tools exist for C), or the
development team has the time and resources to very carefully evolve the code.
What one finds in practice is that authors will wing it and
hub.com/semver/semver/issues/771
> (Don't want to repeat this explanation over and over in many discussions).
>
"One bad programmer can break more than 10 good ones can fix": the issue
you raise is bad engineering (increasing the version number simply because
you can) and is no
- etimmons@, rpgoldman@ "Erik Huelsmann" :> Could you elaborate a bit on "As semver does not work for Common Lisp"? I've opened an issue in the SemVer github repo: https://github.com/semver/semver/issues/771(Don't want to repeat this explanation over and over in many discussions). I will probably r
esire to distinguish alpha versions from stable releases and have alpha ordered before the stable, the following approach makes it possible in the current versioning: alpha version: 3.4.0-alphabeta version: 3.4.1-betastable version: 3.4.2In other words, never publish versions that have equal num
he desire to distinguish alpha versions from
> stable releases and have alpha ordered before the stable, the following
> approach makes it possible in the current versioning:
>
> alpha version: 3.4.0-alpha
> beta version: 3.4.1-beta
> stable version: 3.4.2
>
> In other words,
stable, the following approach makes it possible in the current versioning: alpha version: 3.4.0-alphabeta version: 3.4.1-betastable version: 3.4.2In other words, never publish versions that have equal numeric parts. IMHO there is no significant practical sense in keeping even the least significant
onal epoch prefix.
What might be nice would be to support a /subset/ of semver by
default -- not allowing the numerical prerelease flagged with |-| --
but do so in a way that is extensible.
Here's my rationale: I would like to provide a relatively simple
semantic versioning that is also
numerical prerelease flagged with |-| -- but do so
in a way that is extensible.
Here's my rationale: I would like to provide a relatively simple
semantic versioning that is also compatible with automatically detecting
and rejecting ill-formed version strings.
So, for example, we could (by
ht be nice would be to support a *subset* of semver by default
-- not allowing the numerical prerelease flagged with `-` -- but do so
in a way that is extensible.
Here's my rationale: I would like to provide a relatively simple
semantic versioning that is also compatible with automatically det
That will work with the existing version comparison functions, yes,
because it is still based on "string-encoding-of-number" comparison.
On 17 Nov 2021, at 12:34, Marco Antoniotti wrote:
I decided to switch to version numbers that are dates in MMDD
format.
Looks like it would still work
Robert Goldman wrote:
> Why would that be a win over just calling FORMATTED-VERSION on demand?
>
> I.e., we could just provide something like
>
> (defgeneric FORMATTED-VERSION (C &optional version)
> (:method ((COMPONENT C) &optional version)
> (or version (component-version c)))
>
> and t
On 6/16/15 Jun 16 -10:33 AM, Didier Verna wrote:
> Robert Goldman wrote:
>
>> Just to clarify: I am NOT saying Pascal is wrong to want these things
>> or to do them himself. And I AM saying that ASDF should make it
>> possible for him to do so.
>
> ASDF could call FORMATTED-VERSION itself to
Robert Goldman writes:
> On 6/16/15 Jun 16 -9:31 AM, Didier Verna wrote:
>> Robert Goldman wrote:
>>
>>> Now: a request for management purposes: Didier, would you be so kind
>>> as to describe the proposal (I think cut and paste out of your earlier
>>> emails would do admirably) in a ticket on
Faré writes:
>> “The factory of the future will have only two employees, a man and a
>> dog. The man will be there to feed the dog. The dog will be there to
>> keep the man from touching the equipment.” -- Carl Bass CEO Autodesk
>
> This is a recycled old joke about airplane cockpits. I don't kno
Robert Goldman wrote:
> Just to clarify: I am NOT saying Pascal is wrong to want these things
> or to do them himself. And I AM saying that ASDF should make it
> possible for him to do so.
ASDF could call FORMATTED-VERSION itself to initialize the
corresponding slot (if any), and refrain fr
On 6/16/15 Jun 16 -10:24 AM, Didier Verna wrote:
> Robert Goldman wrote:
>
>> So what happens when the programmer updates the human readable version
>> and not the canonical version, or vice versa? Wouldn't it be better
>> to functionally derive one of these two forms from the other? E.g.,
>> (
Robert Goldman wrote:
> So what happens when the programmer updates the human readable version
> and not the canonical version, or vice versa? Wouldn't it be better
> to functionally derive one of these two forms from the other? E.g.,
> (defgeneric formatted-version (component version-spec))
ld make that
>> version (used by ASDF) and long-version (used by humans).
>
> Works for me, as long as it is also possible to delegate comparison to
> the concerned system. Or, you adopt my personal versioning scheme :-D.
>
Versioning is a can of worms I refrained from opening
On 6/16/15 Jun 16 -9:31 AM, Didier Verna wrote:
> Robert Goldman wrote:
>
>> Now: a request for management purposes: Didier, would you be so kind
>> as to describe the proposal (I think cut and paste out of your earlier
>> emails would do admirably) in a ticket on launchpad.net?
>
> OK. I will
Robert Goldman wrote:
> Now: a request for management purposes: Didier, would you be so kind
> as to describe the proposal (I think cut and paste out of your earlier
> emails would do admirably) in a ticket on launchpad.net?
OK. I will also add Pascal's suggestion to have both a canonical and
I would welcome a restructuring of the version comparison protocol along
the lines that Didier suggests: make sure all the components of the
protocol are properly handled by generic functions, and allow system
developers and maintainers to manage their own version comparison logic
should they so c
e could make that
> version (used by ASDF) and long-version (used by humans).
Works for me, as long as it is also possible to delegate comparison to
the concerned system. Or, you adopt my personal versioning scheme :-D.
--
My new Jazz CD entitled "Roots and Leaves" is out!
Check it out:
On Tue, Jun 16, 2015 at 7:39 AM, Pascal J. Bourguignon
wrote:
> Didier Verna writes:
>
>> Hi,
>>
>> in general, I don't like the way ASDF tries to force you to comply with
>> its own design choices and policy. This is especially true for component
>> v
t; (defsystem :foo
>:version (1 0 42)
>:human-readable-version-string "1.0.gamma.XLII/pescadero:whasa")
Actually, I had something like that in mind. With this idea of
allowing individual systems to handle their own versioning logic, I
intended to put something like
Didier Verna writes:
> Hi,
>
> in general, I don't like the way ASDF tries to force you to comply with
> its own design choices and policy. This is especially true for component
> versioning. ASDF complains that it doesn't like my version numbers
> (which, i
Drake Wilson wrote:
> Curiosity: what _are_ your version numbers like, and how do you
> compare them? It was a little too hard to find this readily from your
> website. Maybe seeing a good example would help.
A version specifier has a major and a minor number, a status (alpha,
beta, release
Didier Verna wrote:
> Hi,
>
> in general, I don't like the way ASDF tries to force you to comply with
> its own design choices and policy. This is especially true for component
> versioning. ASDF complains that it doesn't like my version numbers
> (which, in fact, a
I wrote:
> Thoughts ? Will this be enough to satisfy ASDF ?
Not quite. I missed NORMALIZE-VERSION (ASDF attempting to be clever
and doing all sorts of nasty DWIM stuff on version numbers).
Attached patch would solve the problem, it seems. But then again, I
don't really know what I'm doin
Hi,
in general, I don't like the way ASDF tries to force you to comply with
its own design choices and policy. This is especially true for component
versioning. ASDF complains that it doesn't like my version numbers
(which, in fact, are not only numbers ;-), but I'm not read
> Developers can collaborate to assemble library version
> and share vermaps which are consistent and tested
> to work well together. They can be shared inside
> a company, or globally, like Quicklisp does.
we do that with the dwim.hu libs using darcs repos and tags.
every once in a while, i tag
ASDF was never equipped to resolve versioning constraints, just to
check them. So yes, we need external tools to create assemblies of
mutually-compatible library versions. Quicklisp is such at tool, and
the only one being maintained at this point.
Otherwise, I agree that unless it is both
I want to highlight another tool to deal with versioning.
19.11.2013, 23:41, "Robert P. Goldman" :
> two versions of the same library on the same machine is quite feasible,
> and indeed I do this myself, every day. I have different
> source trees for different projects, and wi
Semantic versioning makes one good thing - it concentrates
on difference between API compatible changes and API
incompatible changes.
This is an important concept and it remains valid
for binary components and for source code.
But semantic versioning is not a complete solution.
It allows to
PI are so odd, unpredictable, and difficult to
> trace to root cause that we should provide what help we can.
>
> That said, there is clearly an *enormous* range of different opinions on
> this issue, and these are all reasoned opinions. So I suggest a compromise:
>
> 1. For
through ASDF
version constraints,
then don't use ASDF version constraints and stick to your extreme ways.
I also vote against "semantic versioning" as a meaningful thing for
Common Lisp code.
It's a great notion for the binary release of C dynamic libraries
that just doesn't me
On Thu, Nov 21, 2013 at 3:56 PM, Anton Vodonosov wrote:
> Fare, I do not understand how you think about versioning.
>
> Why do you say semantic versioning is for binary libraries?
>
Because that's what it was designed for: binary releases of C
libraries, such as /usr/lib/li
The proposal to put new, incompatible version into new package
does not imply any additional maintenance of old versions.
And BTW, other versioning approaches do not prevent
from support of previous versions. These two questions
are completely orthogonal.
If speak about old versions maintenance
d-macros.git
Interesting.
> Back on-topic, semantic versioning systems such as advocated by GNU
> libtool try to provide a conservative estimate on portability.
libtool combines the notions of API and ABI compatibility. We have it a
bit easier.
[...]
> On Tue, 19 Nov 2013, Anton Vo
Fare, I do not understand how you think about versioning.
Why do you say semantic versioning is for binary libraries?
I even suppose you mean something different than
me, Robert and others. Because semantic versioning
as described at http://semver.org/ focuses on distinction
between API
Faré wrote:
> I contend that the provider system, not the consumer system, should
> specify whether it's using semantic versioning or not.
>
> With my proposed :backward-compatible-to keyword, you would specify:
> (defsystem floyd-warshall :version "2.1.4"
should upgrade the provider system, is already the
greatest help we can provide.
> That said, there is clearly an *enormous* range of different opinions on
> this issue, and these are all reasoned opinions. So I suggest a compromise:
>
> 1. For those who like semantic versioning, rever
Stelian Ionescu wrote:
>> > Whatever we do, please implement an escape hatch for the end user to
>> > override the versioning system's idea of compatibility. These things
>> > often have obscure failure modes and/or prevent nuanced usage. Just like
>>
On Thu, 2013-11-21 at 17:51 +0400, Anton Vodonosov wrote:
> The proposal to put new, incompatible version into new package
> does not imply any additional maintenance of old versions.
>
> And BTW, other versioning approaches do not prevent
> from support of previous versions. Thes
f different opinions on
this issue, and these are all reasoned opinions. So I suggest a compromise:
1. For those who like semantic versioning, revert to the behavior that
an expressly indicated API upgrade by the supplier causes a signal to be
conditioned. So if I release floyd-warshall 2.0,
good afternoon;
On 21 Nov 2013, at 12:02 PM, Stelian Ionescu wrote:
> On Wed, 2013-11-20 at 23:24 +0100, Didier Verna wrote:
>> Pascal Costanza wrote:
>>
>>> Just to chime in in the middle: There is no known solution to the
>>> so-called "DLL hell" problem.
>>
>> You're right of course, but in
On Wed, 2013-11-20 at 18:54 +0100, Pascal Costanza wrote:
> Just to chime in in the middle: There is no known solution to the
> so-called "DLL hell" problem. Libraries interact badly because of
> their interactions, not because one or the other is "bad." Even with
> the best of intentions, a librar
On Wed, 2013-11-20 at 23:24 +0100, Didier Verna wrote:
> Pascal Costanza wrote:
>
> > Just to chime in in the middle: There is no known solution to the
> > so-called "DLL hell" problem.
>
> You're right of course, but in practice, I think we have a lot to learn
> from guix/nixos. Ultimately, I w
ptimistic about your approach, but it has two huge advantages:
>
> 1. Unlike my proposal, yours requires no infrastructure support (no
> enforcement in ASDF)
> 2. Your proposal requires no buy-in
>
> What I mean is that anyone can experiment with your approach to library
> versionin
read-macros" package demonstrated some functionality to
simplify writing read-time conditional code without pushing everything on
*features*.
http://git.tentpost.com/?p=lisp/read-macros.git
Back on-topic, semantic versioning systems such as advocated by GNU
libtool try to provide a conservativ
Pascal Costanza wrote:
> Just to chime in in the middle: There is no known solution to the
> so-called "DLL hell" problem.
You're right of course, but in practice, I think we have a lot to learn
from guix/nixos. Ultimately, I would like to see quicklisp and asdf melt
into a beast like that...
-
ple, if I am changing the API, I am the only one who knows
this. So I can signal this by bumping the major version number, and the
first time someone tries to load, cause an exception. Now we can check
the exception, and if it's not important, we simply update the
versioning information and
On Wed, Nov 20, 2013 at 12:54 PM, Pascal Costanza wrote:
> Just to chime in in the middle: There is no known solution to the so-called
> "DLL hell" problem.
Yes there is.
http://nixos.org/nixos/
> Libraries interact badly because of their interactions,
> not because one or the other is "bad." Eve
Just to chime in in the middle: There is no known solution to the so-called
"DLL hell" problem. Libraries interact badly because of their interactions, not
because one or the other is "bad." Even with the best of intentions, a library
author cannot predict what changes will break existing client
es no infrastructure support (no
enforcement in ASDF)
2. Your proposal requires no buy-in
What I mean is that anyone can experiment with your approach to library
versioning simply by following your guidelines for system construction,
and by "branching" a system when its API changes,
I think, you're both right. :)
I have a similar experience of migrating a large Java application through
changes of versions of Jetty from 6th to 9th, and it was much less painful
when the namespaces were changed (between v. 6 and 7 if I'm not mistaken)
for the points mentioned by Anton. So I thin
19.11.2013, 23:41, "Robert P. Goldman" :
> it's too radical
It's not radical, actually my proposal is very similar to yours
> It's like having a purely functional programming language
Yes, I see this as an FP analogy too and expect that avoiding
mutations and destructive changes will simplify lif
Anton Vodonosov wrote:
> Hi Robert.
>
> I would be interested to discuss library versioning.
>
> Lets agree that this discussion is not about fix of
> the moptilities/closer-mop problem, which happens on
> already deployed versions of ASDF which we can not undeploy or fix.
Hi Robert.
I would be interested to discuss library versioning.
Lets agree that this discussion is not about fix of
the moptilities/closer-mop problem, which happens on
already deployed versions of ASDF which we can not undeploy or fix.
moptilities/closer-mop authors can negoticate one o
As for
dynamic libraries; which at least superficially
looks like the same as so called "semantic versioning".
The intent was to help solve DLL hell for Lisp libraries,
but was insufficiently documented, and was lost to the community
when Dan Barlow left.
At the same time, I believe the solution
seems to be a counsel of despair: it says that since
we have a bad state of affairs now, we are doomed to live with it forever.
I suppose I could take a little while and write up a candidate
"versioning systems with ASDF" node for the ASDF manual, and push it for
consideration by the
On 28 April 2011 11:55, wrote:
> - Please slow down the rate for pushing updates into SBCL, etc. The new
> upgrade features make it easier for end users to get what they need.
>
Well, as for SBCL in particular, it has been upgraded five times since
ASDF 2 (including once by mistake to an experim
Faré wrote:
> NB: Meh, shouldn't have gone into this long defense. I somehow took
> dherring's remarks personally and don't have the guts to not post this
> reply after writing it. Please ignore.
I apologize for causing any stress. I worry about "looking the gift horse
in the mouth" and was hopin
NB: Meh, shouldn't have gone into this long defense. I somehow took
dherring's remarks personally and don't have the guts to not post this
reply after writing it. Please ignore.
> In a nutshell, things like changes to inputs (enforcing contracts), outputs
> (changing what's printed) and internal b
On Wed, 27 Apr 2011, Faré wrote:
On 27 April 2011 12:57, wrote:
These are probably good things, but as Zach mentioned, recently ASDF has
started dragging users through internal development. Its a gripe I have
about Slime and some other key libraries, so you are in good company, but
I cannot
On 27 April 2011 14:14, Zach Beane wrote:
> My primary concern is that, if I don't take the time to try out the
> minor commits, a change like the verbosity change would just end up in a
> release. In general, I'd rather see opt-in behavior, which I can ignore
> until persuaded otherwise, than opt
Faré writes:
> On 27 April 2011 12:57, wrote:
>> These are probably good things, but as Zach mentioned, recently ASDF has
>> started dragging users through internal development. Its a gripe I have
>> about Slime and some other key libraries, so you are in good company, but
>> I cannot follow "
On 27 April 2011 12:57, wrote:
> These are probably good things, but as Zach mentioned, recently ASDF has
> started dragging users through internal development. Its a gripe I have
> about Slime and some other key libraries, so you are in good company, but
> I cannot follow "the bleeding edge" as
Faré wrote:
> What's wrong with (mostly) silence?
>
> What about verbosity levels, with an integer indicating what level of
> messages to get?
These are probably good things, but as Zach mentioned, recently ASDF has
started dragging users through internal development. Its a gripe I have
about Sli
75 matches
Mail list logo
