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 dete
On 21 Nov 2013, at 18:45, Robert P. Goldman wrote:
> Faré wrote:
>>> I'm going to take that as a vote to implement a continuation restart for
>>> version mismatch errors. [Yes, I'm grasping at straws! ;-)]
>>>
>> I vote NO to that.
>
> Usually I find myself in agreement with you, but in this
> I'm going to take that as a vote to implement a continuation restart for
> version mismatch errors. [Yes, I'm grasping at straws! ;-)]
>
I vote NO to that.
If the client system specifies a minimum version, it means it,
and any older version is an error that better occur early than late.
If he s
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/libmagic.1.0.0
The versio
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 (
On Thu, 2013-11-21 at 00:36 -0500, Daniel Herring wrote:
[...]
> FWIW, my little "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
Interesting.
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 compatibl
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" :backward-compatible-to "2.0" ...)
>
> A
On Thu, Nov 21, 2013 at 12:45 PM, Robert P. Goldman wrote:
> Faré wrote:
>>> I'm going to take that as a vote to implement a continuation restart for
>>> version mismatch errors. [Yes, I'm grasping at straws! ;-)]
>>>
>> I vote NO to that.
>
> Usually I find myself in agreement with you, but in t
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
>> > CL::internal symbols, it is nice to have
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. These two questions
>
Faré wrote:
>> I'm going to take that as a vote to implement a continuation restart for
>> version mismatch errors. [Yes, I'm grasping at straws! ;-)]
>>
> I vote NO to that.
Usually I find myself in agreement with you, but in this case I find
myself two for two against, so I will share my ration
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
On Wed, 2013-11-20 at 08:54 -0600, Robert P. Goldman wrote:
> Anton Vodonosov wrote:
> > 19.11.2013, 23:41, "Robert P. Goldman" :
> >> it's too radical
> > It's not radical, actually my proposal is very similar to yours
>
> I am not as optimistic about your approach, but it has two huge advantages
On Tue, 19 Nov 2013, Faré wrote:
Thanks to #+foo, #.(if (find-symbol "FOO" :bar) ...)
and (eval-when ...), CL can deal with source-level compatibility
in ways that C cannot.
Moving a bit off-topic, GNU Autoconf takes probing for function
availability and behavior further towards a science tha
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...
-
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 library author cannot predict what change
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
Anton Vodonosov wrote:
> 19.11.2013, 23:41, "Robert P. Goldman" :
>> it's too radical
> It's not radical, actually my proposal is very similar to yours
I am not as optimistic about your approach, but it has two huge advantages:
1. Unlike my proposal, yours requires no infrastructure support (no
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.
> moptilities/closer-mo
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
>>: antonv
>> Note also, in 2009 ASDF didn't consider version "0.6" as satisfying
>> requirement for "0.55":
>
>: rpgoldman
> Yes, that's because the version scheme in ASDF is not a sequence of
> period-separated integers, but a sequence of period-separated strings.
>
I suppose you mean the opposit
Anton Vodonosov wrote:
> The manual says:
> "the :version, :author, description and other [defsystem] fields are not
> required but they provide documentation and information for people that want
> to use this system.
> It also says in the section about asdf:operate:
> "If a version argument is s
28 matches
Mail list logo
